PowerPC, P2020RDB, application debug when the application is in tight loop, Sysrq
HI All,
I am new to this group. I am working on Freescale P2020
platform running linux 2.6.21. I am looking for debug mechanism/utility,
when a multi threaded application running on linux , appears to be hung (
running in a tight loop,deadlock) while not able to access the board
through serial/SSH/Telnet.
I was looking at Magic sysrq option in linux to generate the stack,
register dump when the application is hung. I am able to dump the call
trace in normal working conditions. But i can't use echo t
/proc/sysrq-trigger and debug when the application hung.
I am using below piece of code(drivers/serial/8250.c) on P2020RDB to debug
the application where in , in hung situation, when i press 'y' followed by
't' on serial console it should go to sysrq handler, and dump the call
trace, but it is not happening.(simply board hung)
{
if(sysrq_enable_flag)
handle_sysrq(ch, up-port.info-tty);
sysrq_enable_flag = 0;
if(ch == 'y')
sysrq_enable_flag = 1;
}
It would be helpful if you provide any hint on the issue, or any other way
to debug the application in hang situations.
Thanks,
Sai
On Tue, Apr 16, 2013 at 9:24 PM, Anshuman Khandual
khand...@linux.vnet.ibm.com wrote:
Branch History Rolling Buffer (BHRB) is a new PMU feaure
in IBM
POWER8 processor which records the branch instructions inside the execution
pipeline. This patchset enables the basic functionality of the feature
through
generic perf branch stack sampling framework.
Sample output
-
$./perf record -b top
$./perf report
Overhead Command Source Shared Object Source
Symbol Target Shared ObjectTarget Symbol
# ...
..
...
#
7.82% top libc-2.11.2.so[k] _IO_vfscanf
libc-2.11.2.so[k] _IO_vfscanf
6.17% top libc-2.11.2.so[k] _IO_vfscanf
[unknown] [k]
2.37% top [unknown] [k] 0xf7aafb30
[unknown] [k]
1.80% top [unknown] [k] 0x0fe07978
libc-2.11.2.so[k] _IO_vfscanf
1.60% top libc-2.11.2.so[k] _IO_vfscanf
[kernel.kallsyms] [k] .do_task_stat
1.20% top [kernel.kallsyms] [k] .do_task_stat
[kernel.kallsyms] [k] .do_task_stat
1.02% top libc-2.11.2.so[k] vfprintf
libc-2.11.2.so[k] vfprintf
0.92% top top [k] _init
[unknown] [k] 0x0fe037f4
Changes in V2
--
- Added copyright messages to the newly created files
- Modified couple of commit messages
Anshuman Khandual (5):
powerpc, perf: Add new BHRB related instructions on POWER8
powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
powerpc, perf: Add new BHRB related generic functions, data and flags
powerpc, perf: Define BHRB generic functions, data and flags for POWER8
powerpc, perf: Enable branch stack sampling framework support with BHRB
arch/powerpc/include/asm/perf_event_server.h | 6 ++
arch/powerpc/include/asm/ppc-opcode.h| 7 ++
arch/powerpc/perf/Makefile | 2 +-
arch/powerpc/perf/bhrb.S | 44 +
arch/powerpc/perf/core-book3s.c | 96
+++-
arch/powerpc/perf/perf_event_bhrb.c | 85
arch/powerpc/perf/power8-pmu.c | 57 -
7 files changed, 292 insertions(+), 5 deletions(-)
create mode 100644 arch/powerpc/perf/bhrb.S
create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 5/5] powerpc, perf: Enable branch stack sampling framework support with BHRB
On Tue, Apr 16, 2013 at 09:24:10PM +0530, Anshuman Khandual wrote:
This patch provides basic enablement for perf branch stack sampling framework
on POWER8 processor with a new PMU feature called BHRB (Branch History Rolling
Buffer).
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 96
+++--
arch/powerpc/perf/perf_event_bhrb.c | 85
2 files changed, 178 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 4ac6e64..f4d1347 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -19,6 +19,8 @@
#include asm/firmware.h
#include asm/ptrace.h
+#define BHRB_MAX_ENTRIES 32
+
struct cpu_hw_events {
int n_events;
int n_percpu;
@@ -38,11 +40,21 @@ struct cpu_hw_events {
unsigned int group_flag;
int n_txn_start;
+
+ /* BHRB bits */
+ u64 bhrb_filter;/* BHRB HW branch
filter */
+ int bhrb_users;
+ void*bhrb_context;
+ struct perf_branch_stack bhrb_stack;
+ struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
};
+
DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
struct power_pmu *ppmu;
+#include perf_event_bhrb.c
+
Um, why are you doing that?
If it's code that should be in a header, put it in a header. If it's C
code, add it to the Makefile.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: remove the unneeded trigger of decrementer interrupt in decrementer_check_overflow
Previously in order to handle the edge sensitive decrementers, we choose to set the decrementer to 1 to trigger a decrementer interrupt when re-enabling interrupts. But with the rework of the lazy EE, we would replay the decrementer interrupt when re-enabling interrupts if a decrementer interrupt occurs with irq soft-disabled. So there is no need to trigger a decrementer interrupt in this case any more. Signed-off-by: Kevin Hao haoke...@gmail.com --- arch/powerpc/kernel/irq.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c index 4f97fe3..1af5744 100644 --- a/arch/powerpc/kernel/irq.c +++ b/arch/powerpc/kernel/irq.c @@ -116,8 +116,6 @@ static inline notrace int decrementer_check_overflow(void) u64 now = get_tb_or_rtc(); u64 *next_tb = __get_cpu_var(decrementers_next_tb); - if (now = *next_tb) - set_dec(1); return now = *next_tb; } -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] usb: remove redundant tdi_reset
We remove the redundant tdi_reset in ehci_setup since there is already it in ehci_reset. It was observed that the duplicated tdi_reset was causing the PHY_CLK_VALID bit unstable. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- drivers/usb/host/ehci-hcd.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 416a6dc..83b5a17 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -670,9 +670,6 @@ int ehci_setup(struct usb_hcd *hcd) if (retval) return retval; - if (ehci_is_TDI(ehci)) - tdi_reset(ehci); - ehci_reset(ehci); return 0; -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
Tang Yuantian-B29983 wrote: It was placed on ELSE statement originally, I moved it to IF statement. Why is it so wrong? Because the logic of the comment applies to the else-condition, not the if-condtion. -- Timur Tabi ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] Enable CONFIG_DEVTMPFS_MOUNT to ensure /dev can be mounted correctly
-Original Message- From: Michael Ellerman [mailto:mich...@ellerman.id.au] Sent: Monday, April 15, 2013 1:02 PM On Thu, Apr 11, 2013 at 09:56:30PM +0800, Zhenhua Luo wrote: When using recent udev, the /dev node mount requires CONFIG_DEVTMPFS_MOUNT is enabled in Kernel. Really? I know it makes life easier when you don't have an initramfs, but is it actually required now? [Luo Zhenhua-B19537] I didn't use initramfs when the issue is found, I think the option is required to be enabled. Best Regards, Zhenhua ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 5/5] powerpc, perf: Enable branch stack sampling framework support with BHRB
On 04/17/2013 12:38 PM, Michael Ellerman wrote:
On Tue, Apr 16, 2013 at 09:24:10PM +0530, Anshuman Khandual wrote:
This patch provides basic enablement for perf branch stack sampling framework
on POWER8 processor with a new PMU feature called BHRB (Branch History
Rolling
Buffer).
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 96
+++--
arch/powerpc/perf/perf_event_bhrb.c | 85
2 files changed, 178 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
diff --git a/arch/powerpc/perf/core-book3s.c
b/arch/powerpc/perf/core-book3s.c
index 4ac6e64..f4d1347 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -19,6 +19,8 @@
#include asm/firmware.h
#include asm/ptrace.h
+#define BHRB_MAX_ENTRIES32
+
struct cpu_hw_events {
int n_events;
int n_percpu;
@@ -38,11 +40,21 @@ struct cpu_hw_events {
unsigned int group_flag;
int n_txn_start;
+
+/* BHRB bits */
+u64 bhrb_filter;/* BHRB HW branch
filter */
+int bhrb_users;
+void*bhrb_context;
+struct perf_branch_stack bhrb_stack;
+struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
};
+
DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
struct power_pmu *ppmu;
+#include perf_event_bhrb.c
+
Um, why are you doing that?
There was no specific reason for that.
If it's code that should be in a header, put it in a header. If it's C
code, add it to the Makefile.
Sure I would get the new code in the Makefile. Thanks!
Regards
Anshuman
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Enable CONFIG_DEVTMPFS_MOUNT to ensure /dev can be mounted correctly
On 2013-04-17 05:46, Luo Zhenhua-B19537 wrote: -Original Message- From: Michael Ellerman [mailto:mich...@ellerman.id.au] Sent: Monday, April 15, 2013 1:02 PM On Thu, Apr 11, 2013 at 09:56:30PM +0800, Zhenhua Luo wrote: When using recent udev, the /dev node mount requires CONFIG_DEVTMPFS_MOUNT is enabled in Kernel. Really? I know it makes life easier when you don't have an initramfs, but is it actually required now? [Luo Zhenhua-B19537] I didn't use initramfs when the issue is found, I think the option is required to be enabled. Yes, it is required to get udev to work properly (versions of udev newer than ~173) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c |8 +---
drivers/gpu/drm/radeon/rv770.c |8 +---
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..3291f62 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
{
- u32 link_width_cntl, speed_cntl, mask;
- int ret;
+ u32 link_width_cntl, speed_cntl;
if (radeon_pcie_gen2 == 0)
return;
@@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct radeon_device
*rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
For devices on a root bus, we previously dereferenced a NULL pointer
in drm_pcie_get_speed_cap_mask() because pdev-bus-self is NULL on a
root bus. (I think this is the original problem you tripped over,
Lucas.)
These patches fix that problem. On pseries, where the device *is* on
a root bus, your patches set max_bus_speed so this will work as
expected. On most other systems, max_bus_speed for root buses will be
PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
most arches don't have code like the pseries code you're adding).
PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
the root bus, we'll attempt to enable Gen2 on the device even though
we have no idea what the bus will support.
That's why I originally suggested skipping the Gen2 stuff if
max_bus_speed == PCI_SPEED_UNKNOWN. I was just being conservative,
thinking that it's better to have a functional but slow GPU rather
than the unknown (to me) effects of enabling Gen2 on a link that might
not support it. But I'm fine with this being either way.
You're right here, of course. I'll test for it being different from
5_0GT and 8_0GT instead. Though at some point I suppose someone will
want to tackle Gen3 speeds.
It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
altogether. It is exported, but I have no idea of anybody else uses
it. Maybe it could at least be marked __deprecated now?
I'll mark it.
I don't know who should take these patches. They don't touch
drivers/pci, but I'd be happy to push them, given the appropriate ACKs
from DRM and powerpc folks.
Bjorn
return;
speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0740db3..64b90c0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -4351,8 +4351,6 @@ static void r600_pcie_gen2_enable(struct radeon_device
*rdev)
{
u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
u16 link_cntl2;
- u32 mask;
- int ret;
if (radeon_pcie_gen2 == 0)
return;
@@ -4371,11 +4369,7 @@ static void r600_pcie_gen2_enable(struct radeon_device
*rdev)
if (rdev-family= CHIP_R600)
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
return;
speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index d63fe1d..c683c36 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1238,8 +1238,6 @@ static void rv770_pcie_gen2_enable(struct radeon_device
*rdev)
{
u32 link_width_cntl, lanes, speed_cntl, tmp;
u16 link_cntl2;
- u32 mask;
- int ret;
if (radeon_pcie_gen2 == 0)
return;
@@ -1254,11 +1252,7 @@ static void rv770_pcie_gen2_enable(struct radeon_device
*rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
return;
DRM_INFO(enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0\n);
--
1.7.4.4
--
Lucas Kannebley Tavares
Software Engineer
IBM Linux
Re: [PATCHv3 1/2] ppc64: perform proper max_bus_speed detection
On 04/15/2013 02:00 AM, Michael Ellerman wrote: On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote: On pseries machines the detection for max_bus_speed should be done through an OpenFirmware property. This patch adds a function to perform this detection and a hook to perform dynamic adding of the function only for pseries. The crucial detail you didn't mention is that pcibios_root_bridge_prepare() already exists as a weak function in the PCI code and is called from pci_create_root_bus(). Adding this comment. diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c index 8bcc9ca..15796b5 100644 --- a/arch/powerpc/platforms/pseries/setup.c +++ b/arch/powerpc/platforms/pseries/setup.c @@ -430,6 +430,8 @@ static void pSeries_machine_kexec(struct kimage *image) } #endif +int pseries_root_bridge_prepare(struct pci_host_bridge *bridge); + Don't do that, put it in a header where it belongs. And done as well. cheers -- Lucas Kannebley Tavares Software Engineer IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 1/2] ppc64: perform proper max_bus_speed detection
On 04/15/2013 08:42 AM, Michael Ellerman wrote: On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote: On pseries machines the detection for max_bus_speed should be done through an OpenFirmware property. This patch adds a function to perform this detection and a hook to perform dynamic adding of the function only for pseries. This fails to build for me on ppc64_defconfig, with: arch/powerpc/include/asm/machdep.h:111:5: error: 'struct pci_host_bridge' declared inside parameter list [-Werror] Presumably you tested it using some other defconfig? cheers Yes, I tested with another config, I did get warnings, though, so I should've fixed that earlier. Adding a forward declaration to prevent this from even throwing out warnings. -- Lucas Kannebley Tavares Software Engineer IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
On Tue, 16 Apr 2013 06:54:40 +, Tang Yuantian-B29983 b29...@freescale.com wrote: Hi Grant.likely, I really preciate if you can spend some times to review this patch. Applied, thanks. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] usb: remove redundant tdi_reset
On Wed, 17 Apr 2013, Shengzhou Liu wrote: We remove the redundant tdi_reset in ehci_setup since there is already it in ehci_reset. It was observed that the duplicated tdi_reset was causing the PHY_CLK_VALID bit unstable. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- drivers/usb/host/ehci-hcd.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 416a6dc..83b5a17 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -670,9 +670,6 @@ int ehci_setup(struct usb_hcd *hcd) if (retval) return retval; - if (ehci_is_TDI(ehci)) - tdi_reset(ehci); - ehci_reset(ehci); return 0; Acked-by: Alan Stern st...@rowland.harvard.edu This should be applied to stable kernels going back to 3.6. In case you are wondering why that redudant call was added, I did it because some of the PCI drivers (Intel and TDI) already had calls to tdi_reset. The commit removed those calls, so the new one was added in. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] of/pci: mips: convert to common of_pci_range_parser
On Tue, Apr 16, 2013 at 12:18 PM, Andrew Murray andrew.mur...@arm.com wrote: This patch converts the pci_load_of_ranges function to use the new common of_pci_range_parser. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com wrote: On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Linus Walleij linus.wall...@linaro.org Acked-by: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 arch/powerpc/include/asm/pci-bridge.h|5 +- arch/powerpc/kernel/pci-common.c | 192 Is there anyone on linuxppc-dev/linux-mips that can help test this patchset? I've tested that it builds on powerpc with a variety of configs (some which include fsl_pci.c implementation). Though I don't have hardware to verify that it works. I haven't tested this builds or runs on MIPS. You shouldn't see any difference in behaviour or new warnings and PCI devices should continue to operate as before. I've got through a line-by-line comparison between powerpc, microblaze, and then new code. The differences are purely cosmetic, so I have absolutely no concerns about this patch. I've applied it to my tree. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote: On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com wrote: On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Linus Walleij linus.wall...@linaro.org Acked-by: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 arch/powerpc/include/asm/pci-bridge.h|5 +- arch/powerpc/kernel/pci-common.c | 192 Is there anyone on linuxppc-dev/linux-mips that can help test this patchset? I've tested that it builds on powerpc with a variety of configs (some which include fsl_pci.c implementation). Though I don't have hardware to verify that it works. I haven't tested this builds or runs on MIPS. You shouldn't see any difference in behaviour or new warnings and PCI devices should continue to operate as before. I've got through a line-by-line comparison between powerpc, microblaze, and then new code. The differences are purely cosmetic, so I have absolutely no concerns about this patch. I've applied it to my tree. oops. Due to the number of dependencies the mvebu-pcie series has (this being one of them, we (arm-soc/mvebu) asked if we could take this through our tree. Rob Herring agreed to this several days ago. Is this a problem for you? It would truly (dogs and cats living together) upset the apple cart for us at this stage to pipe these through a different tree... thx, Jason. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper ja...@lakedaemon.net wrote: On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote: On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com wrote: On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Linus Walleij linus.wall...@linaro.org Acked-by: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 arch/powerpc/include/asm/pci-bridge.h|5 +- arch/powerpc/kernel/pci-common.c | 192 Is there anyone on linuxppc-dev/linux-mips that can help test this patchset? I've tested that it builds on powerpc with a variety of configs (some which include fsl_pci.c implementation). Though I don't have hardware to verify that it works. I haven't tested this builds or runs on MIPS. You shouldn't see any difference in behaviour or new warnings and PCI devices should continue to operate as before. I've got through a line-by-line comparison between powerpc, microblaze, and then new code. The differences are purely cosmetic, so I have absolutely no concerns about this patch. I've applied it to my tree. oops. Due to the number of dependencies the mvebu-pcie series has (this being one of them, we (arm-soc/mvebu) asked if we could take this through our tree. Rob Herring agreed to this several days ago. Is this a problem for you? It would truly (dogs and cats living together) upset the apple cart for us at this stage to pipe these through a different tree... Not a problem at all. I'll drop it. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] of/pci: Unify pci_process_bridge_OF_ranges from Microblaze and PowerPC
On Wed, Apr 17, 2013 at 05:17:48PM +0100, Grant Likely wrote: On Wed, Apr 17, 2013 at 5:10 PM, Jason Cooper ja...@lakedaemon.net wrote: On Wed, Apr 17, 2013 at 05:00:15PM +0100, Grant Likely wrote: On Tue, 16 Apr 2013 11:30:06 +0100, Andrew Murray andrew.mur...@arm.com wrote: On Tue, Apr 16, 2013 at 11:18:26AM +0100, Andrew Murray wrote: The pci_process_bridge_OF_ranges function, used to parse the ranges property of a PCI host device, is found in both Microblaze and PowerPC architectures. These implementations are nearly identical. This patch moves this common code to a common place. Signed-off-by: Andrew Murray andrew.mur...@arm.com Signed-off-by: Liviu Dudau liviu.du...@arm.com Reviewed-by: Rob Herring rob.herr...@calxeda.com Tested-by: Thomas Petazzoni thomas.petazz...@free-electrons.com Tested-by: Linus Walleij linus.wall...@linaro.org Acked-by: Michal Simek mon...@monstr.eu --- arch/microblaze/include/asm/pci-bridge.h |5 +- arch/microblaze/pci/pci-common.c | 192 arch/powerpc/include/asm/pci-bridge.h|5 +- arch/powerpc/kernel/pci-common.c | 192 Is there anyone on linuxppc-dev/linux-mips that can help test this patchset? I've tested that it builds on powerpc with a variety of configs (some which include fsl_pci.c implementation). Though I don't have hardware to verify that it works. I haven't tested this builds or runs on MIPS. You shouldn't see any difference in behaviour or new warnings and PCI devices should continue to operate as before. I've got through a line-by-line comparison between powerpc, microblaze, and then new code. The differences are purely cosmetic, so I have absolutely no concerns about this patch. I've applied it to my tree. oops. Due to the number of dependencies the mvebu-pcie series has (this being one of them, we (arm-soc/mvebu) asked if we could take this through our tree. Rob Herring agreed to this several days ago. Is this a problem for you? It would truly (dogs and cats living together) upset the apple cart for us at this stage to pipe these through a different tree... Not a problem at all. I'll drop it. Great! Thanks. Jason. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
questions around Book III-E and branch trace
Hi, I'm trying to wrap my head around how linux handles branch tracing on Book III-E. I think I understand how we set MSR[DE] and DBCR0[IDM|BT], and how we handle fixing things up if an instruction being traced causes an exception. I have a few questions though: 1) Does user_enable_block_step() have a bug in it? The current code has task-thread.dbcr0 = DBCR0_IDM | DBCR0_BT; Should that be as follows (to match the singel-step case)? task-thread.dbcr0 |= DBCR0_IDM | DBCR0_BT; 2) Why doesn't DBCR0_ACTIVE_EVENTS include DBCR0_BT? 3) In sys_debug_setcontext() why does SIG_DBG_BRANCH_TRACING return -EINVAL if CONFIG_PPC_ADV_DEBUG_REGS is set? Would it not be possible to use DBCR0_BT? Thanks, Chris -- Chris Friesen Software Designer 500 Palladium Drive, Suite 2100 Ottawa, Ontario K2N 1C2, Canada www.genband.com office:+1.343.883.2717 chris.frie...@genband.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c |8 +---
drivers/gpu/drm/radeon/rv770.c |8 +---
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..3291f62 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
{
- u32 link_width_cntl, speed_cntl, mask;
- int ret;
+ u32 link_width_cntl, speed_cntl;
if (radeon_pcie_gen2 == 0)
return;
@@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct
radeon_device *rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
For devices on a root bus, we previously dereferenced a NULL pointer
in drm_pcie_get_speed_cap_mask() because pdev-bus-self is NULL on a
root bus. (I think this is the original problem you tripped over,
Lucas.)
These patches fix that problem. On pseries, where the device *is* on
a root bus, your patches set max_bus_speed so this will work as
expected. On most other systems, max_bus_speed for root buses will be
PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
most arches don't have code like the pseries code you're adding).
PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
the root bus, we'll attempt to enable Gen2 on the device even though
we have no idea what the bus will support.
That's why I originally suggested skipping the Gen2 stuff if
max_bus_speed == PCI_SPEED_UNKNOWN. I was just being conservative,
thinking that it's better to have a functional but slow GPU rather
than the unknown (to me) effects of enabling Gen2 on a link that might
not support it. But I'm fine with this being either way.
You're right here, of course. I'll test for it being different from 5_0GT
and 8_0GT instead. Though at some point I suppose someone will want to
tackle Gen3 speeds.
drm_pcie_get_speed_cap_mask() actually checked the pci bridge to see
what speeds it supported. If the new code doesn't actually check the
bridge caps then the new code does not seem like a valid replacement
unless I'm missing something.
Alex
It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
altogether. It is exported, but I have no idea of anybody else uses
it. Maybe it could at least be marked __deprecated now?
I'll mark it.
I don't know who should take these patches. They don't touch
drivers/pci, but I'd be happy to push them, given the appropriate ACKs
from DRM and powerpc folks.
Bjorn
return;
speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/r600.c
b/drivers/gpu/drm/radeon/r600.c
index 0740db3..64b90c0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -4351,8 +4351,6 @@ static void r600_pcie_gen2_enable(struct
radeon_device *rdev)
{
u32 link_width_cntl, lanes, speed_cntl, training_cntl, tmp;
u16 link_cntl2;
- u32 mask;
- int ret;
if (radeon_pcie_gen2 == 0)
return;
@@ -4371,11 +4369,7 @@ static void r600_pcie_gen2_enable(struct
radeon_device *rdev)
if (rdev-family= CHIP_R600)
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
return;
speed_cntl = RREG32_PCIE_P(PCIE_LC_SPEED_CNTL);
diff --git a/drivers/gpu/drm/radeon/rv770.c
b/drivers/gpu/drm/radeon/rv770.c
index d63fe1d..c683c36 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1238,8 +1238,6 @@ static void rv770_pcie_gen2_enable(struct
radeon_device *rdev)
{
u32 link_width_cntl, lanes, speed_cntl, tmp;
u16 link_cntl2;
- u32 mask;
- int ret;
if (radeon_pcie_gen2 == 0)
return;
@@ -1254,11 +1252,7 @@ static void rv770_pcie_gen2_enable(struct
radeon_device *rdev)
if
Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c |8 +---
drivers/gpu/drm/radeon/rv770.c |8 +---
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..3291f62 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
{
- u32 link_width_cntl, speed_cntl, mask;
- int ret;
+ u32 link_width_cntl, speed_cntl;
if (radeon_pcie_gen2 == 0)
return;
@@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct
radeon_device *rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
For devices on a root bus, we previously dereferenced a NULL pointer
in drm_pcie_get_speed_cap_mask() because pdev-bus-self is NULL on a
root bus. (I think this is the original problem you tripped over,
Lucas.)
These patches fix that problem. On pseries, where the device *is* on
a root bus, your patches set max_bus_speed so this will work as
expected. On most other systems, max_bus_speed for root buses will be
PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
most arches don't have code like the pseries code you're adding).
PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
the root bus, we'll attempt to enable Gen2 on the device even though
we have no idea what the bus will support.
That's why I originally suggested skipping the Gen2 stuff if
max_bus_speed == PCI_SPEED_UNKNOWN. I was just being conservative,
thinking that it's better to have a functional but slow GPU rather
than the unknown (to me) effects of enabling Gen2 on a link that might
not support it. But I'm fine with this being either way.
You're right here, of course. I'll test for it being different from 5_0GT
and 8_0GT instead. Though at some point I suppose someone will want to
tackle Gen3 speeds.
drm_pcie_get_speed_cap_mask() actually checked the pci bridge to see
what speeds it supported. If the new code doesn't actually check the
bridge caps then the new code does not seem like a valid replacement
unless I'm missing something.
The max_bus_speed in struct pci_bus is set in pci_set_bus_speed()
based on the PCIe, PCI-X, or AGP capabilities. This happens when we
enumerate the bridge device. Or, in this case, Lucas added
powerpc-specific code to set max_bus_speed for the root bus based on
platform-specific host bridge knowledge.
So it still does check the PCI bridge capabilities, just not as
directly as it did before.
Bjorn
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c |8 +---
drivers/gpu/drm/radeon/rv770.c |8 +---
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..3291f62 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
{
- u32 link_width_cntl, speed_cntl, mask;
- int ret;
+ u32 link_width_cntl, speed_cntl;
if (radeon_pcie_gen2 == 0)
return;
@@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct
radeon_device *rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
For devices on a root bus, we previously dereferenced a NULL pointer
in drm_pcie_get_speed_cap_mask() because pdev-bus-self is NULL on a
root bus. (I think this is the original problem you tripped over,
Lucas.)
These patches fix that problem. On pseries, where the device *is* on
a root bus, your patches set max_bus_speed so this will work as
expected. On most other systems, max_bus_speed for root buses will be
PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
most arches don't have code like the pseries code you're adding).
PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
the root bus, we'll attempt to enable Gen2 on the device even though
we have no idea what the bus will support.
That's why I originally suggested skipping the Gen2 stuff if
max_bus_speed == PCI_SPEED_UNKNOWN. I was just being conservative,
thinking that it's better to have a functional but slow GPU rather
than the unknown (to me) effects of enabling Gen2 on a link that might
not support it. But I'm fine with this being either way.
You're right here, of course. I'll test for it being different from 5_0GT
and 8_0GT instead. Though at some point I suppose someone will want to
tackle Gen3 speeds.
drm_pcie_get_speed_cap_mask() actually checked the pci bridge to see
what speeds it supported. If the new code doesn't actually check the
bridge caps then the new code does not seem like a valid replacement
unless I'm missing something.
The max_bus_speed in struct pci_bus is set in pci_set_bus_speed()
based on the PCIe, PCI-X, or AGP capabilities. This happens when we
enumerate the bridge device. Or, in this case, Lucas added
powerpc-specific code to set max_bus_speed for the root bus based on
platform-specific host bridge knowledge.
So it still does check the PCI bridge capabilities, just not as
directly as it did before.
Ah, ok. Thanks. The previous comments about PCI_SPEED_UNKNOWN being
set in pci_alloc_bus() and never updated confused me.
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
On Wed, Apr 17, 2013 at 2:17 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
luca...@linux.vnet.ibm.com wrote:
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the max_bus_speed attribute.
---
drivers/gpu/drm/radeon/evergreen.c |9 ++---
drivers/gpu/drm/radeon/r600.c |8 +---
drivers/gpu/drm/radeon/rv770.c |8 +---
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 305a657..3291f62 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
{
- u32 link_width_cntl, speed_cntl, mask;
- int ret;
+ u32 link_width_cntl, speed_cntl;
if (radeon_pcie_gen2 == 0)
return;
@@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct
radeon_device *rdev)
if (ASIC_IS_X2(rdev))
return;
- ret = drm_pcie_get_speed_cap_mask(rdev-ddev,mask);
- if (ret != 0)
- return;
-
- if (!(mask DRM_PCIE_SPEED_50))
+ if (rdev-pdev-bus-max_bus_speed PCIE_SPEED_5_0GT)
For devices on a root bus, we previously dereferenced a NULL pointer
in drm_pcie_get_speed_cap_mask() because pdev-bus-self is NULL on a
root bus. (I think this is the original problem you tripped over,
Lucas.)
These patches fix that problem. On pseries, where the device *is* on
a root bus, your patches set max_bus_speed so this will work as
expected. On most other systems, max_bus_speed for root buses will be
PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
most arches don't have code like the pseries code you're adding).
PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
the root bus, we'll attempt to enable Gen2 on the device even though
we have no idea what the bus will support.
That's why I originally suggested skipping the Gen2 stuff if
max_bus_speed == PCI_SPEED_UNKNOWN. I was just being conservative,
thinking that it's better to have a functional but slow GPU rather
than the unknown (to me) effects of enabling Gen2 on a link that might
not support it. But I'm fine with this being either way.
You're right here, of course. I'll test for it being different from 5_0GT
and 8_0GT instead. Though at some point I suppose someone will want to
tackle Gen3 speeds.
drm_pcie_get_speed_cap_mask() actually checked the pci bridge to see
what speeds it supported. If the new code doesn't actually check the
bridge caps then the new code does not seem like a valid replacement
unless I'm missing something.
The max_bus_speed in struct pci_bus is set in pci_set_bus_speed()
based on the PCIe, PCI-X, or AGP capabilities. This happens when we
enumerate the bridge device. Or, in this case, Lucas added
powerpc-specific code to set max_bus_speed for the root bus based on
platform-specific host bridge knowledge.
So it still does check the PCI bridge capabilities, just not as
directly as it did before.
Ah, ok. Thanks. The previous comments about PCI_SPEED_UNKNOWN being
set in pci_alloc_bus() and never updated confused me.
Yeah, that's just for root buses where we don't have the host bridge
knowledge to figure it out. The root bus case was broken in
drm_pcie_get_speed_cap_mask() anyway, because there is no upstream P2P
bridge to look at. (That's why Lucas tripped over the null pointer
dereference in the first place.)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] serial/mpc52xx_uart: add MPC5125 PSC support
From: Matteo Facchinetti matteo.facchine...@sirius-es.it
Add MPC5125 PSC register layout structure, MPC5125 specific
psc_ops function set and the compatible string.
Signed-off-by: Vladimir Ermakov vooon...@gmail.com
Signed-off-by: Matteo Facchinetti matteo.facchine...@sirius-es.it
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes in v2:
- split into two patches to simplify review
- minor coding style changes
- revise commit log
arch/powerpc/include/asm/mpc52xx_psc.h | 49 +++
drivers/tty/serial/mpc52xx_uart.c | 241
2 files changed, 290 insertions(+)
diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h
b/arch/powerpc/include/asm/mpc52xx_psc.h
index 2966df6..d0ece25 100644
--- a/arch/powerpc/include/asm/mpc52xx_psc.h
+++ b/arch/powerpc/include/asm/mpc52xx_psc.h
@@ -299,4 +299,53 @@ struct mpc512x_psc_fifo {
#define rxdata_32 rxdata.rxdata_32
};
+struct mpc5125_psc {
+ u8 mr1;/* PSC + 0x00 */
+ u8 reserved0[3];
+ u8 mr2;/* PSC + 0x04 */
+ u8 reserved1[3];
+ struct {
+ u16 status; /* PSC + 0x08 */
+ u8 reserved2[2];
+ u8 clock_select; /* PSC + 0x0c */
+ u8 reserved3[3];
+ } sr_csr;
+ u8 command;/* PSC + 0x10 */
+ u8 reserved4[3];
+ union { /* PSC + 0x14 */
+ u8 buffer_8;
+ u16 buffer_16;
+ u32 buffer_32;
+ } buffer;
+ struct {
+ u8 ipcr; /* PSC + 0x18 */
+ u8 reserved5[3];
+ u8 acr;/* PSC + 0x1c */
+ u8 reserved6[3];
+ } ipcr_acr;
+ struct {
+ u16 isr;/* PSC + 0x20 */
+ u8 reserved7[2];
+ u16 imr;/* PSC + 0x24 */
+ u8 reserved8[2];
+ } isr_imr;
+ u8 ctur; /* PSC + 0x28 */
+ u8 reserved9[3];
+ u8 ctlr; /* PSC + 0x2c */
+ u8 reserved10[3];
+ u32 ccr;/* PSC + 0x30 */
+ u32 ac97slots; /* PSC + 0x34 */
+ u32 ac97cmd;/* PSC + 0x38 */
+ u32 ac97data; /* PSC + 0x3c */
+ u8 reserved11[4];
+ u8 ip; /* PSC + 0x44 */
+ u8 reserved12[3];
+ u8 op1;/* PSC + 0x48 */
+ u8 reserved13[3];
+ u8 op0;/* PSC + 0x4c */
+ u8 reserved14[3];
+ u32 sicr; /* PSC + 0x50 */
+ u8 reserved15[4]; /* make eq. sizeof(mpc52xx_psc) */
+};
+
#endif /* __ASM_MPC52xx_PSC_H__ */
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tty/serial/mpc52xx_uart.c
index 5aa87ac..9c3eab5 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -658,6 +658,246 @@ static void mpc512x_psc_get_irq(struct uart_port *port,
struct device_node *np)
port-irqflags = IRQF_SHARED;
port-irq = psc_fifoc_irq;
}
+#endif
+
+#ifdef CONFIG_PPC_MPC512x
+
+#define PSC_5125(port) ((struct mpc5125_psc __iomem *)((port)-membase))
+#define FIFO_5125(port) ((struct mpc512x_psc_fifo __iomem *)(PSC_5125(port)+1))
+
+static void mpc5125_psc_fifo_init(struct uart_port *port)
+{
+ /* /32 prescaler */
+ out_8(PSC_5125(port)-mpc52xx_psc_clock_select, 0xdd);
+
+ out_be32(FIFO_5125(port)-txcmd, MPC512x_PSC_FIFO_RESET_SLICE);
+ out_be32(FIFO_5125(port)-txcmd, MPC512x_PSC_FIFO_ENABLE_SLICE);
+ out_be32(FIFO_5125(port)-txalarm, 1);
+ out_be32(FIFO_5125(port)-tximr, 0);
+
+ out_be32(FIFO_5125(port)-rxcmd, MPC512x_PSC_FIFO_RESET_SLICE);
+ out_be32(FIFO_5125(port)-rxcmd, MPC512x_PSC_FIFO_ENABLE_SLICE);
+ out_be32(FIFO_5125(port)-rxalarm, 1);
+ out_be32(FIFO_5125(port)-rximr, 0);
+
+ out_be32(FIFO_5125(port)-tximr, MPC512x_PSC_FIFO_ALARM);
+ out_be32(FIFO_5125(port)-rximr, MPC512x_PSC_FIFO_ALARM);
+}
+
+static int mpc5125_psc_raw_rx_rdy(struct uart_port *port)
+{
+ return !(in_be32(FIFO_5125(port)-rxsr) MPC512x_PSC_FIFO_EMPTY);
+}
+
+static int mpc5125_psc_raw_tx_rdy(struct uart_port *port)
+{
+ return !(in_be32(FIFO_5125(port)-txsr) MPC512x_PSC_FIFO_FULL);
+}
+
+static int mpc5125_psc_rx_rdy(struct uart_port *port)
+{
+ return in_be32(FIFO_5125(port)-rxsr)
+ in_be32(FIFO_5125(port)-rximr)
[PATCH v2 1/2] serial/mpc52xx_uart: prepare for adding MPC5125 PSC UART support
From: Matteo Facchinetti matteo.facchine...@sirius-es.it
MPC5125 PSC controller has different register layout than MPC5121.
To support MPC5125 PSC in this driver we have to provide further
psc_ops functions for SoC specific register accesses.
Add new register access functions to the psc_ops structure and
provide MPC52xx and MPC512x specific implementation for them.
Then replace remaining direct register accesses in the driver by
appropriate psc_ops function calls. The subsequent patch can now
add MPC5125 specific set of psc_ops functions.
Signed-off-by: Vladimir Ermakov vooon...@gmail.com
Signed-off-by: Matteo Facchinetti matteo.facchine...@sirius-es.it
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Greg, with your Acked-by I can push these patches to my mpc5xxx tree.
But it is fine with me if you prefer to apply them to tty tree.
Thanks,
Anatolij
Changes in v2:
- split into two patches to simplify review
- minor coding style changes
- revise commit log
drivers/tty/serial/mpc52xx_uart.c | 161 +++--
1 file changed, 119 insertions(+), 42 deletions(-)
diff --git a/drivers/tty/serial/mpc52xx_uart.c
b/drivers/tty/serial/mpc52xx_uart.c
index 018bad9..5aa87ac 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -122,6 +122,15 @@ struct psc_ops {
void(*fifoc_uninit)(void);
void(*get_irq)(struct uart_port *, struct device_node *);
irqreturn_t (*handle_irq)(struct uart_port *port);
+ u16 (*get_status)(struct uart_port *port);
+ u8 (*get_ipcr)(struct uart_port *port);
+ void(*command)(struct uart_port *port, u8 cmd);
+ void(*set_mode)(struct uart_port *port, u8 mr1, u8 mr2);
+ void(*set_rts)(struct uart_port *port, int state);
+ void(*enable_ms)(struct uart_port *port);
+ void(*set_sicr)(struct uart_port *port, u32 val);
+ void(*set_imr)(struct uart_port *port, u16 val);
+ u8 (*get_mr1)(struct uart_port *port);
};
/* setting the prescaler and divisor reg is common for all chips */
@@ -134,6 +143,65 @@ static inline void mpc52xx_set_divisor(struct mpc52xx_psc
__iomem *psc,
out_8(psc-ctlr, divisor 0xff);
}
+static u16 mpc52xx_psc_get_status(struct uart_port *port)
+{
+ return in_be16(PSC(port)-mpc52xx_psc_status);
+}
+
+static u8 mpc52xx_psc_get_ipcr(struct uart_port *port)
+{
+ return in_8(PSC(port)-mpc52xx_psc_ipcr);
+}
+
+static void mpc52xx_psc_command(struct uart_port *port, u8 cmd)
+{
+ out_8(PSC(port)-command, cmd);
+}
+
+static void mpc52xx_psc_set_mode(struct uart_port *port, u8 mr1, u8 mr2)
+{
+ out_8(PSC(port)-command, MPC52xx_PSC_SEL_MODE_REG_1);
+ out_8(PSC(port)-mode, mr1);
+ out_8(PSC(port)-mode, mr2);
+}
+
+static void mpc52xx_psc_set_rts(struct uart_port *port, int state)
+{
+ if (state)
+ out_8(PSC(port)-op1, MPC52xx_PSC_OP_RTS);
+ else
+ out_8(PSC(port)-op0, MPC52xx_PSC_OP_RTS);
+}
+
+static void mpc52xx_psc_enable_ms(struct uart_port *port)
+{
+ struct mpc52xx_psc __iomem *psc = PSC(port);
+
+ /* clear D_*-bits by reading them */
+ in_8(psc-mpc52xx_psc_ipcr);
+ /* enable CTS and DCD as IPC interrupts */
+ out_8(psc-mpc52xx_psc_acr, MPC52xx_PSC_IEC_CTS | MPC52xx_PSC_IEC_DCD);
+
+ port-read_status_mask |= MPC52xx_PSC_IMR_IPC;
+ out_be16(psc-mpc52xx_psc_imr, port-read_status_mask);
+}
+
+static void mpc52xx_psc_set_sicr(struct uart_port *port, u32 val)
+{
+ out_be32(PSC(port)-sicr, val);
+}
+
+static void mpc52xx_psc_set_imr(struct uart_port *port, u16 val)
+{
+ out_be16(PSC(port)-mpc52xx_psc_imr, val);
+}
+
+static u8 mpc52xx_psc_get_mr1(struct uart_port *port)
+{
+ out_8(PSC(port)-command, MPC52xx_PSC_SEL_MODE_REG_1);
+ return in_8(PSC(port)-mode);
+}
+
#ifdef CONFIG_PPC_MPC52xx
#define FIFO_52xx(port) ((struct mpc52xx_psc_fifo __iomem *)(PSC(port)+1))
static void mpc52xx_psc_fifo_init(struct uart_port *port)
@@ -304,6 +372,15 @@ static struct psc_ops mpc52xx_psc_ops = {
.set_baudrate = mpc5200_psc_set_baudrate,
.get_irq = mpc52xx_psc_get_irq,
.handle_irq = mpc52xx_psc_handle_irq,
+ .get_status = mpc52xx_psc_get_status,
+ .get_ipcr = mpc52xx_psc_get_ipcr,
+ .command = mpc52xx_psc_command,
+ .set_mode = mpc52xx_psc_set_mode,
+ .set_rts = mpc52xx_psc_set_rts,
+ .enable_ms = mpc52xx_psc_enable_ms,
+ .set_sicr = mpc52xx_psc_set_sicr,
+ .set_imr = mpc52xx_psc_set_imr,
+ .get_mr1 = mpc52xx_psc_get_mr1,
};
static struct psc_ops mpc5200b_psc_ops = {
@@ -325,6 +402,15 @@ static struct psc_ops mpc5200b_psc_ops = {
.set_baudrate = mpc5200b_psc_set_baudrate,
.get_irq = mpc52xx_psc_get_irq,
.handle_irq = mpc52xx_psc_handle_irq,
+ .get_status =
Re: [PATCH 2/3] serial/mpc52xx_uart: add PSC UART support for MPC5125 platforms.
On Wed, 20 Mar 2013 18:41:53 +0100 Matteo Facchinetti matteo.facchine...@sirius-es.it wrote: MPC5125 PSC controller has different registers than MPC5121. This patch was originally created by Vladimir Ermakov https://lists.ozlabs.org/pipermail/linuxppc-dev/2011-March/088954.html Signed-off-by: Vladimir Ermakov vooon...@gmail.com Signed-off-by: Matteo Facchinetti matteo.facchine...@sirius-es.it --- arch/powerpc/include/asm/mpc52xx_psc.h | 49 drivers/tty/serial/mpc52xx_uart.c | 407 2 files changed, 414 insertions(+), 42 deletions(-) This patch should be better split to add SoC specific register accessors first, then we can add mpc5125 changes by separate patch. I've just done this splitting and added more descriptive commit log. Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
On Wed, Apr 17, 2013 at 9:57 AM, Grant Likely grant.lik...@secretlab.ca wrote: I really preciate if you can spend some times to review this patch. Applied, thanks. Pff. Why do I bother? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] of/base: release the node correctly in of_parse_phandle_with_args()
On Wed, Apr 17, 2013 at 10:52 PM, Timur Tabi ti...@tabi.org wrote: On Wed, Apr 17, 2013 at 9:57 AM, Grant Likely grant.lik...@secretlab.ca wrote: I really preciate if you can spend some times to review this patch. Applied, thanks. Pff. Why do I bother? Relax Timur: http://git.secretlab.ca/?p=linux.git;a=commitdiff;h=b855f16b05a697ac1863adabe99bfba56e6d3199 g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BUG: branch trace support for 64-bit Book-E (was Re: questions around Book III-E and branch trace)
On 04/17/2013 12:44 PM, Chris Friesen wrote: Hi, I'm trying to wrap my head around how linux handles branch tracing on Book III-E. I think I understand how we set MSR[DE] and DBCR0[IDM|BT], and how we handle fixing things up if an instruction being traced causes an exception. While poking around looking for answers to my previous questions I seem to have stumbled over a bug in branch tracing for 64-bit Book-E. Commit ec097c8 added support for branch tracing for 32-bit code, but didn't do the 64-bit path. As it stands, debug_crit/debug_debug in exceptions-64e.S only check DBSR_IC, so branch tracing will not get fixed up and will die a horrible death (typically in a tbr exception handler). I was banging my head trying to figure out why this wasn't working when I finally clued in to the fact that head_booke.h only applied to the 32-bit implementation. This might be something useful to put in a comment up at the top of the file. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Erroneous double irq_eoi() on CPM IRQ in MPC8xx
irq_eoi() is already called by generic_handle_irq() so
it shall not be called a again
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
Index: linux/arch/powerpc/platforms/8xx/m8xx_setup.c
===
--- linux/arch/powerpc/platforms/8xx/m8xx_setup.c (revision 4802)
+++ linux/arch/powerpc/platforms/8xx/m8xx_setup.c (working copy)
@@ -218,19 +218,12 @@
static void cpm_cascade(unsigned int irq, struct irq_desc *desc)
{
- struct irq_chip *chip;
- int cascade_irq;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ int cascade_irq = cpm_get_irq());
- if ((cascade_irq = cpm_get_irq()) = 0) {
- struct irq_desc *cdesc = irq_to_desc(cascade_irq);
-
+ if (cascade_irq = 0)
generic_handle_irq(cascade_irq);
- chip = irq_desc_get_chip(cdesc);
- chip-irq_eoi(cdesc-irq_data);
- }
-
- chip = irq_desc_get_chip(desc);
chip-irq_eoi(desc-irq_data);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH powerpc] make CONFIG_NUMA depends on CONFIG_SMP
On Wed, May 30, 2012 at 05:31:58PM +0800, Li Zhong wrote: I'm not sure whether it makes sense to add this dependency to avoid CONFI_NUMA !CONFIG_SMP. I want to do this because I saw some build errors on next-tree when compiling with CONFIG_SMP disabled, and it seems they are caused by some codes under the CONFIG_NUMA #ifdefs. This seems to make sense to me. Can you please repost with a better changelog and a description of the actual build error you were seeing. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 5/5] powerpc, perf: Enable branch stack sampling framework support with BHRB
On 04/17/2013 05:37 PM, Anshuman Khandual wrote:
On 04/17/2013 12:38 PM, Michael Ellerman wrote:
On Tue, Apr 16, 2013 at 09:24:10PM +0530, Anshuman Khandual wrote:
This patch provides basic enablement for perf branch stack sampling
framework
on POWER8 processor with a new PMU feature called BHRB (Branch History
Rolling
Buffer).
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 96
+++--
arch/powerpc/perf/perf_event_bhrb.c | 85
2 files changed, 178 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/perf/perf_event_bhrb.c
diff --git a/arch/powerpc/perf/core-book3s.c
b/arch/powerpc/perf/core-book3s.c
index 4ac6e64..f4d1347 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -19,6 +19,8 @@
#include asm/firmware.h
#include asm/ptrace.h
+#define BHRB_MAX_ENTRIES 32
+
struct cpu_hw_events {
int n_events;
int n_percpu;
@@ -38,11 +40,21 @@ struct cpu_hw_events {
unsigned int group_flag;
int n_txn_start;
+
+ /* BHRB bits */
+ u64 bhrb_filter;/* BHRB HW branch
filter */
+ int bhrb_users;
+ void*bhrb_context;
+ struct perf_branch_stack bhrb_stack;
+ struct perf_branch_entry bhrb_entries[BHRB_MAX_ENTRIES];
};
+
DEFINE_PER_CPU(struct cpu_hw_events, cpu_hw_events);
struct power_pmu *ppmu;
+#include perf_event_bhrb.c
+
Um, why are you doing that?
There was no specific reason for that.
Ahh, I remember it now. The function in the new file uses cpu_hw_events
structure
which is passed during record_and_restart data capture phase. Right now
cpu_hw_events is
not defined in the header file but inside core-book3s.c itself. Solution to
this problem
could be any of these.
(0) Move all the code from the new file perf_event_bhrb.c into core-book3s.c
(1) Move cpu_hw_events structure to perf_event_server.h
(2) Create additional BHRB processing function inside struct power_pmu and
define it for P8 inside power8_pmu.c
Regards
Anshuman
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
AUTO: Michael Barry is out of the office (returning 24/04/2013)
I am out of the office until 24/04/2013. Note: This is an automated response to your message Linuxppc-dev Digest, Vol 104, Issue 108 sent on 17/04/2013 21:17:28. This is the only notification you will receive while this person is away. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add HWCAP2 aux entry
We are currently out of free bits in AT_HWCAP. With POWER8, we have
several hardware features that we need to advertise.
Tested on POWER and x86.
Signed-off-by: Michael Neuling mich...@neuling.org
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
Wouldn't it be safer to not emit AT_HWCAP2 unless it is defined by the arch?
That way the change would only impact powerpc.
Should be addressed with this version.
Mikey
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index fb3245e..ccadad6 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -52,6 +52,7 @@ struct cpu_spec {
char*cpu_name;
unsigned long cpu_features; /* Kernel features */
unsigned intcpu_user_features; /* Userland features */
+ unsigned intcpu_user_features2; /* Userland features v2 */
unsigned intmmu_features; /* MMU features */
/* cache line sizes */
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index ac9790f..cc0655a 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -61,6 +61,7 @@ typedef elf_vrregset_t elf_fpxregset_t;
instruction set this cpu supports. This could be done in userspace,
but it's not easy, and we've already done it here. */
# define ELF_HWCAP (cur_cpu_spec-cpu_user_features)
+# define ELF_HWCAP2(cur_cpu_spec-cpu_user_features2)
/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3939829..1f8b5d5 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -240,6 +240,9 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr
*exec,
NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred-user_ns, cred-egid));
NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
+#ifdef ELF_HWCAP2
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
+#endif
NEW_AUX_ENT(AT_EXECFN, bprm-exec);
if (k_platform) {
NEW_AUX_ENT(AT_PLATFORM,
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 9c13e02..bf2381d 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -483,7 +483,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
size_t platform_len = 0, len;
char *k_platform, *k_base_platform;
char __user *u_platform, *u_base_platform, *p;
- long hwcap;
int loop;
int nr; /* reset for each csp adjustment */
@@ -502,8 +501,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
return -EFAULT;
#endif
- hwcap = ELF_HWCAP;
-
/*
* If this architecture has a platform capability string, copy it
* to userspace. In some cases (Sparc), this info is impossible
@@ -617,7 +614,10 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
nr = 0;
csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
- NEW_AUX_ENT(AT_HWCAP, hwcap);
+ NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
+#ifdef ELF_HWCAP2
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
+#endif
NEW_AUX_ENT(AT_PAGESZ, PAGE_SIZE);
NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
NEW_AUX_ENT(AT_PHDR,exec_params-ph_addr);
diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
index 61594d5..835c065 100644
--- a/include/uapi/linux/auxvec.h
+++ b/include/uapi/linux/auxvec.h
@@ -28,6 +28,7 @@
#define AT_BASE_PLATFORM 24/* string identifying real platform, may
* differ from AT_PLATFORM. */
#define AT_RANDOM 25 /* address of 16 random bytes */
+#define AT_HWCAP2 26 /* extension of AT_HWCAP */
#define AT_EXECFN 31 /* filename of program */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add HWCAP2 aux entry
akpm,
If you're happy with this, is it something you can take in your tree?
Mikey
Michael Neuling mi...@neuling.org wrote:
We are currently out of free bits in AT_HWCAP. With POWER8, we have
several hardware features that we need to advertise.
Tested on POWER and x86.
Signed-off-by: Michael Neuling mich...@neuling.org
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
Wouldn't it be safer to not emit AT_HWCAP2 unless it is defined by the arch?
That way the change would only impact powerpc.
Should be addressed with this version.
Mikey
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index fb3245e..ccadad6 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -52,6 +52,7 @@ struct cpu_spec {
char*cpu_name;
unsigned long cpu_features; /* Kernel features */
unsigned intcpu_user_features; /* Userland features */
+ unsigned intcpu_user_features2; /* Userland features v2 */
unsigned intmmu_features; /* MMU features */
/* cache line sizes */
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index ac9790f..cc0655a 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -61,6 +61,7 @@ typedef elf_vrregset_t elf_fpxregset_t;
instruction set this cpu supports. This could be done in userspace,
but it's not easy, and we've already done it here. */
# define ELF_HWCAP (cur_cpu_spec-cpu_user_features)
+# define ELF_HWCAP2 (cur_cpu_spec-cpu_user_features2)
/* This yields a string that ld.so will use to load implementation
specific libraries for optimization. This is more specific in
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3939829..1f8b5d5 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -240,6 +240,9 @@ create_elf_tables(struct linux_binprm *bprm, struct
elfhdr *exec,
NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred-user_ns, cred-egid));
NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
+#ifdef ELF_HWCAP2
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
+#endif
NEW_AUX_ENT(AT_EXECFN, bprm-exec);
if (k_platform) {
NEW_AUX_ENT(AT_PLATFORM,
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 9c13e02..bf2381d 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -483,7 +483,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
size_t platform_len = 0, len;
char *k_platform, *k_base_platform;
char __user *u_platform, *u_base_platform, *p;
- long hwcap;
int loop;
int nr; /* reset for each csp adjustment */
@@ -502,8 +501,6 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
return -EFAULT;
#endif
- hwcap = ELF_HWCAP;
-
/*
* If this architecture has a platform capability string, copy it
* to userspace. In some cases (Sparc), this info is impossible
@@ -617,7 +614,10 @@ static int create_elf_fdpic_tables(struct linux_binprm
*bprm,
nr = 0;
csp -= DLINFO_ITEMS * 2 * sizeof(unsigned long);
- NEW_AUX_ENT(AT_HWCAP, hwcap);
+ NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
+#ifdef ELF_HWCAP2
+ NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
+#endif
NEW_AUX_ENT(AT_PAGESZ, PAGE_SIZE);
NEW_AUX_ENT(AT_CLKTCK, CLOCKS_PER_SEC);
NEW_AUX_ENT(AT_PHDR,exec_params-ph_addr);
diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h
index 61594d5..835c065 100644
--- a/include/uapi/linux/auxvec.h
+++ b/include/uapi/linux/auxvec.h
@@ -28,6 +28,7 @@
#define AT_BASE_PLATFORM 24 /* string identifying real platform, may
* differ from AT_PLATFORM. */
#define AT_RANDOM 25 /* address of 16 random bytes */
+#define AT_HWCAP2 26 /* extension of AT_HWCAP */
#define AT_EXECFN 31/* filename of program */
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Suggestion] PowerPC: kernel: memory access violation when rtas_data_buf contents are more than 1026
Hello Maintainers:
in arch/powerpc/kernel/lparcfg.c, parse_system_parameter_string()
need set '\0' for 'local_buffer'.
the reason is:
SPLPAR_MAXLENGTH is 1026, RTAS_DATA_BUF_SIZE is 4096
the contents of rtas_data_buf may truncated in memcpy (line 301).
if contents are truncated.
the splpar_strlen is more than 1026 (line 321)
the while loop checking will not find the end of buffer (line 326)
it will cause memory access violation.
I find it by reading code, so please help check.
thanks.
gchen.
-related fix patch--
diff --git a/arch/powerpc/kernel/lparcfg.c b/arch/powerpc/kernel/lparcfg.c
index 801a757..d92f387 100644
--- a/arch/powerpc/kernel/lparcfg.c
+++ b/arch/powerpc/kernel/lparcfg.c
@@ -299,6 +299,7 @@ static void parse_system_parameter_string(struct seq_file
*m)
__pa(rtas_data_buf),
RTAS_DATA_BUF_SIZE);
memcpy(local_buffer, rtas_data_buf, SPLPAR_MAXLENGTH);
+ local_buffer[SPLPAR_MAXLENGTH - 1] = '\0';
spin_unlock(rtas_data_buf_lock);
if (call_status != 0) {
-related source code
283 static void parse_system_parameter_string(struct seq_file *m)
284 {
285 int call_status;
286
287 unsigned char *local_buffer = kmalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
288 if (!local_buffer) {
289 printk(KERN_ERR %s %s kmalloc failure at line %d\n,
290__FILE__, __func__, __LINE__);
291 return;
292 }
293
294 spin_lock(rtas_data_buf_lock);
295 memset(rtas_data_buf, 0, SPLPAR_MAXLENGTH);
296 call_status = rtas_call(rtas_token(ibm,get-system-parameter), 3,
1,
297 NULL,
298 SPLPAR_CHARACTERISTICS_TOKEN,
299 __pa(rtas_data_buf),
300 RTAS_DATA_BUF_SIZE);
301 memcpy(local_buffer, rtas_data_buf, SPLPAR_MAXLENGTH);
302 spin_unlock(rtas_data_buf_lock);
303
304 if (call_status != 0) {
305 printk(KERN_INFO
306%s %s Error calling get-system-parameter (0x%x)\n,
307__FILE__, __func__, call_status);
308 } else {
309 int splpar_strlen;
310 int idx, w_idx;
311 char *workbuffer = kzalloc(SPLPAR_MAXLENGTH, GFP_KERNEL);
312 if (!workbuffer) {
313 printk(KERN_ERR %s %s kmalloc failure at line
%d\n,
314__FILE__, __func__, __LINE__);
315 kfree(local_buffer);
316 return;
317 }
318 #ifdef LPARCFG_DEBUG
319 printk(KERN_INFO success calling get-system-parameter\n);
320 #endif
321 splpar_strlen = local_buffer[0] * 256 + local_buffer[1];
322 local_buffer += 2; /* step over strlen value */
323
324 w_idx = 0;
325 idx = 0;
326 while ((*local_buffer) (idx splpar_strlen)) {
327 workbuffer[w_idx++] = local_buffer[idx++];
328 if ((local_buffer[idx] == ',')
329 || (local_buffer[idx] == '\0')) {
330 workbuffer[w_idx] = '\0';
331 if (w_idx) {
332 /* avoid the empty string */
333 seq_printf(m, %s\n, workbuffer);
334 }
335 memset(workbuffer, 0, SPLPAR_MAXLENGTH);
336 idx++; /* skip the comma */
337 w_idx = 0;
338 } else if (local_buffer[idx] == '=') {
339 /* code here to replace workbuffer contents
340with different keyword strings */
341 if (0 == strcmp(workbuffer, MaxEntCap)) {
342 strcpy(workbuffer,
343
partition_max_entitled_capacity);
344 w_idx = strlen(workbuffer);
345 }
346 if (0 == strcmp(workbuffer,
MaxPlatProcs)) {
347 strcpy(workbuffer,
348
system_potential_processors);
349 w_idx = strlen(workbuffer);
350 }
351 }
352 }
353 kfree(workbuffer);
354 local_buffer -= 2; /*
[PATCH v2] Erroneous double irq_eoi() on CPM IRQ in MPC8xx
irq_eoi() is already called by generic_handle_irq() so
it shall not be called a again
Signed-off-by: Christophe Leroy christophe.le...@c-s.fr
Index: linux/arch/powerpc/platforms/8xx/m8xx_setup.c
===
--- linux/arch/powerpc/platforms/8xx/m8xx_setup.c (revision 4802)
+++ linux/arch/powerpc/platforms/8xx/m8xx_setup.c (working copy)
@@ -218,19 +218,12 @@
static void cpm_cascade(unsigned int irq, struct irq_desc *desc)
{
- struct irq_chip *chip;
- int cascade_irq;
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ int cascade_irq = cpm_get_irq();
- if ((cascade_irq = cpm_get_irq()) = 0) {
- struct irq_desc *cdesc = irq_to_desc(cascade_irq);
-
+ if (cascade_irq = 0)
generic_handle_irq(cascade_irq);
- chip = irq_desc_get_chip(cdesc);
- chip-irq_eoi(cdesc-irq_data);
- }
-
- chip = irq_desc_get_chip(desc);
chip-irq_eoi(desc-irq_data);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Use tlbiel for 4KB pages
The firmware should have supplied correct information for the kernel
to figure out the page size array, which is traced by mmu_psize_defs[].
Otherwise, the kernel will fail back to use solely 4KB page size
and copy mmu_psize_defaults_old[] over to mmu_psize_defs[]. However,
the tlbiel isn't enabled in mmu_psize_defaults_old[].
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/mm/hash_utils_64.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 2d4a20c..8675ae5 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -130,7 +130,7 @@ static struct mmu_psize_def mmu_psize_defaults_old[] = {
.sllp = 0,
.penc = 0,
.avpnm = 0,
- .tlbiel = 0,
+ .tlbiel = 1,
},
};
--
1.7.5.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [RFC] powerpc: Add VDSO version of time
On Mon, Apr 08, 2013 at 11:05:50AM -0300, Adhemerval Zanella wrote: On 04/05/2013 03:21 AM, Michael Ellerman wrote: On Tue, Mar 19, 2013 at 04:55:31PM -0300, Adhemerval Zanella wrote: Hi all, This patch implement the time syscall as vDSO. I have a glibc patch to use it as IFUNC (as latest gettimeofday patch). Below the perf numbers: Baseline PPC32: 380 nsec Baseline PPC64: 352 nsec vdso PPC32: 20 nsec vdso PPC64: 20 nsec I focused on 64 bit kernel, do I need to provide a scheme for 32 bits as well? You did provide a 32-bit implementation. I take it you haven't tested that though? Can you test it? Hi, I didn't build a 32 bit kernel, but I tested 32 bits binaries (that uses the VDSO32 implantation) without any issue. Performance gains are similar. OK. Please send an updated version of the patch which a changelog describing the testing you've done, and add your Signed-off-by to the patch. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
