Re: [patch 1/3] powerpc: Move 64bit VDSO to improve context switch performance
On Tue, 2009-07-14 at 16:53 +1000, Anton Blanchard wrote: plain text document attachment (move_vdso_v2) On 64bit applications the VDSO is the only thing in segment 0. Since the VDSO is position independent we can remove the hint and let get_unmapped_area pick an area. This will mean the vdso will be near other mmaps and will share an SLB entry: Don't we lose randomization ? Or do we randomize the whole mem map nowadays ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 0/3] PowerPC context switch optimisations
Here are a few optimisations that improve context switch performance. -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[patch 3/3] powerpc: Preload application text segment instead of TASK_UNMAPPED_BASE
TASK_UNMAPPED_BASE is not used with the new top down mmap layout. We can
reuse this preload slot by loading in the segment at 0x1000, where almost
all PowerPC binaries are linked at.
On a microbenchmark that bounces a token between two 64bit processes over pipes
and calls gettimeofday each iteration (to access the VDSO), both the 32bit and
64bit context switch rate improves (tested on a 4GHz POWER6):
32bit: 273k/sec - 283k/sec
64bit: 277k/sec - 284k/sec
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: linux.trees.git/arch/powerpc/mm/slb.c
===
--- linux.trees.git.orig/arch/powerpc/mm/slb.c 2009-07-14 15:09:39.0
+1000
+++ linux.trees.git/arch/powerpc/mm/slb.c 2009-07-14 15:12:42.0
+1000
@@ -191,7 +191,7 @@
unsigned long slbie_data = 0;
unsigned long pc = KSTK_EIP(tsk);
unsigned long stack = KSTK_ESP(tsk);
- unsigned long unmapped_base;
+ unsigned long exec_base;
if (!cpu_has_feature(CPU_FTR_NO_SLBIE_B)
offset = SLB_CACHE_ENTRIES) {
@@ -219,14 +219,13 @@
/*
* preload some userspace segments into the SLB.
+* Almost all 32 and 64bit PowerPC executables are linked at
+* 0x1000 so it makes sense to preload this segment.
*/
- if (test_tsk_thread_flag(tsk, TIF_32BIT))
- unmapped_base = TASK_UNMAPPED_BASE_USER32;
- else
- unmapped_base = TASK_UNMAPPED_BASE_USER64;
+ exec_base = 0x1000;
if (is_kernel_addr(pc) || is_kernel_addr(stack) ||
- is_kernel_addr(unmapped_base))
+ is_kernel_addr(exec_base))
return;
slb_allocate(pc);
@@ -234,9 +233,9 @@
if (!esids_match(pc, stack))
slb_allocate(stack);
- if (!esids_match(pc, unmapped_base)
- !esids_match(stack, unmapped_base))
- slb_allocate(unmapped_base);
+ if (!esids_match(pc, exec_base)
+ !esids_match(stack, exec_base))
+ slb_allocate(exec_base);
}
static inline void patch_slb_encoding(unsigned int *insn_addr,
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 3/3] powerpc: Preload application text segment instead of TASK_UNMAPPED_BASE
On Tue, 2009-07-14 at 16:53 +1000, Anton Blanchard wrote: plain text document attachment (preload_0x1000) TASK_UNMAPPED_BASE is not used with the new top down mmap layout. We can reuse this preload slot by loading in the segment at 0x1000, where almost all PowerPC binaries are linked at. On a microbenchmark that bounces a token between two 64bit processes over pipes and calls gettimeofday each iteration (to access the VDSO), both the 32bit and 64bit context switch rate improves (tested on a 4GHz POWER6): 32bit: 273k/sec - 283k/sec 64bit: 277k/sec - 284k/sec Any chance you can put that little test program online somewhere ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 3/3] powerpc: Preload application text segment instead of TASK_UNMAPPED_BASE
Hi Ben, Any chance you can put that little test program online somewhere ? Sure, it's here: http://ozlabs.org/~anton/junkcode/context_switch.c Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [patch 1/3] powerpc: Move 64bit VDSO to improve context switch performance
Hi Ben, Don't we lose randomization ? Or do we randomize the whole mem map nowadays ? The start of the top down mmap region is randomized, so the VDSO will be in a different position each time. A quick example: run 1: fffb01f6000-fffb01f9000 r-xp 00:00 0 [vdso] fffb01f9000-fffb01fa000 r--p 00027000 08:06 4333852 /lib64/ld-2.9.so fffb01fa000-fffb01fd000 rw-p 00028000 08:06 4333852 /lib64/ld-2.9.so fffb01fd000-fffb01fe000 rw-p 00:00 0 7c6f000-7c84000 rw-p 00:00 0 [stack] run 2: fff9a094000-fff9a097000 r-xp 00:00 0 [vdso] fff9a097000-fff9a098000 r--p 00027000 08:06 4333852 /lib64/ld-2.9.so fff9a098000-fff9a09b000 rw-p 00028000 08:06 4333852 /lib64/ld-2.9.so fff9a09b000-fff9a09c000 rw-p 00:00 0 fffea0a6000-fffea0bb000 rw-p 00:00 0 [stack] You will notice we aren't randomising each mmap, so the relative offset between ld.so and the vdso will be consistent. I just checked and it looks like x86 does the same. It might make sense to add a small amount of randomness between mmaps on both x86 and PowerPC, at least for 64bit applications where we have enough address space. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Don't scan for TBI PHY addresses on MPC8569E-MDS boards
On Wed, Jul 01, 2009 at 09:39:25PM +0400, Anton Vorontsov wrote:
Sometimes (e.g. when there are no UEMs attached to a board)
fsl_pq_mdio_find_free() fails to find a spare address for a TBI PHY,
this is because get_phy_id() returns bogus 0x values
(0x is expected), and therefore mdio bus probing fails with
the following message:
fsl-pq_mdio: probe of e0082120.mdio failed with error -16
And obviously ethernet doesn't work after this.
This patch solves the problem by adding tbi-phy node into mdio node,
so that we won't scan for spare addresses, we'll just use a fixed one.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
Kumar,
I believe this patch is suitable for 2.6.31, no?
Thanks,
---
arch/powerpc/boot/dts/mpc8569mds.dts |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts
b/arch/powerpc/boot/dts/mpc8569mds.dts
index 2577f37..baa4ac7 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -502,6 +502,10 @@
reg = 0x6;
device_type = ethernet-phy;
};
+ tbi-...@11 {
+ reg = 0x11;
+ device_type = tbi-phy;
+ };
};
m...@3520 {
#address-cells = 1;
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Fix ethernet link detection on MPC8569E-MDS boards
On Wed, Jun 24, 2009 at 08:30:28PM +0400, Anton Vorontsov wrote:
Linux isn't able to detect link changes on ethernet ports that were
used by U-Boot. This is because U-Boot wrongly clears interrupt
polarity bit (INTPOL, 0x400) in the extended status register (EXT_SR,
0x1b) of Marvell PHYs.
There is no easy way for PHY drivers to know IRQ line polarity (we
could extract it from the device tree and pass it to phydevs, but
that'll be quite a lot of work), so for now just reset the PHYs to
their default states.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
I think this should be safe for 2.6.31...
Thanks,
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index 3268c95..34664c0 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -223,6 +223,19 @@ static void __init mpc85xx_mds_setup_arch(void)
/* Turn UCC1 UCC2 on */
setbits8(bcsr_regs[8], BCSR_UCC1_GETH_EN);
setbits8(bcsr_regs[9], BCSR_UCC2_GETH_EN);
+ } else if (machine_is(mpc8569_mds)) {
+#define BCSR7_UCC12_GETHnRST (0x1 2)
+#define BCSR8_UEM_MARVELL_RST(0x1 1)
+ /*
+ * U-Boot mangles interrupt polarity for Marvell PHYs,
+ * so reset built-in and UEM Marvell PHYs, this puts
+ * the PHYs into their normal state.
+ */
+ clrbits8(bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ setbits8(bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
+
+ setbits8(bcsr_regs[7], BCSR7_UCC12_GETHnRST);
+ clrbits8(bcsr_regs[8], BCSR8_UEM_MARVELL_RST);
}
iounmap(bcsr_regs);
}
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] fs_enet/mii-fec.c: fix MII speed calculation
The MII speed calculation was based on the CPU clock (ppc_proc_freq),
but for MPC512x we must use the bus clock instead.
This patch makes it use the correct clock and makes sure we don't
clobber reserved bits in the MII_SPEED register.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: net...@vger.kernel.org
---
Note 1: This patch is a rewrite of a previous posting:
http://patchwork.ozlabs.org/patch/28584/
Note 2: Function mpc5xxx_get_mii_speed() was introduced for re-use
in a later patch to drivers/net/fec_mpc52xx.c and
drivers/net/fec_mpc52xx_phy.c, which also contain code to
calculate the MII speed without taking care to check for
overflow or to write only the bits that belong to the
MII_SPEED field when setting the MII speed.
arch/powerpc/sysdev/mpc5xxx_clocks.c | 37 ++
drivers/net/fs_enet/mii-fec.c| 13 +--
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc5xxx_clocks.c
b/arch/powerpc/sysdev/mpc5xxx_clocks.c
index 34e12f9..e26d12b 100644
--- a/arch/powerpc/sysdev/mpc5xxx_clocks.c
+++ b/arch/powerpc/sysdev/mpc5xxx_clocks.c
@@ -31,3 +31,40 @@ mpc5xxx_get_bus_frequency(struct device_node *node)
return p_bus_freq ? *p_bus_freq : 0;
}
EXPORT_SYMBOL(mpc5xxx_get_bus_frequency);
+
+/**
+ * mpc5xxx_get_mii_speed - Get the MII_SPEED value
+ * @node: device node
+ *
+ * Returns the MII_SPEED value for MPC512x and MPC52xx systems.
+ * The value gets computed such that the resulting MDC frequency
+ * is 2.5 MHz or lower.
+ */
+
+int
+mpc5xxx_get_mii_speed(struct of_device *ofdev)
+{
+ unsigned int clock, speed;
+
+ clock = mpc5xxx_get_bus_frequency(ofdev-node);
+
+ if (!clock) {
+ dev_err(ofdev-dev, could not determine IPS/IPB clock\n);
+ return -ENODEV;
+ }
+
+ /* scale for a MII clock = 2.5 MHz */
+ speed = (clock + 249) / 250;
+
+ /* only 6 bits available for MII speed */
+ if (speed 0x3F) {
+ speed = 0x3F;
+ dev_err(ofdev-dev,
+ MII clock (%d MHz) exceeds max (2.5 MHz)\n,
+ clock / speed);
+ }
+
+ /* Field is in bits 25:30 of MII_SPEED register */
+ return speed 1;
+}
+EXPORT_SYMBOL(mpc5xxx_get_mii_speed);
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 75a0999..a28d39f 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -36,6 +36,7 @@
#include asm/pgtable.h
#include asm/irq.h
#include asm/uaccess.h
+#include asm/mpc5xxx.h
#include fs_enet.h
#include fec.h
@@ -103,7 +104,6 @@ static int fs_enet_fec_mii_reset(struct mii_bus *bus)
static int __devinit fs_enet_mdio_probe(struct of_device *ofdev,
const struct of_device_id *match)
{
- struct device_node *np = NULL;
struct resource res;
struct mii_bus *new_bus;
struct fec_info *fec;
@@ -133,13 +133,20 @@ static int __devinit fs_enet_mdio_probe(struct of_device
*ofdev,
if (!fec-fecp)
goto out_fec;
- fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1;
+ if (of_device_is_compatible(ofdev-node, fsl,mpc5121-fec-mdio)) {
+ i = mpc5xxx_get_mii_speed(ofdev);
+ if (i 0)
+ goto out_unmap_regs;
+ fec-mii_speed = i;
+ } else {
+ fec-mii_speed = ((ppc_proc_freq + 499) / 500) 1;
+ }
setbits32(fec-fecp-fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(fec-fecp-fec_ecntrl, FEC_ECNTRL_PINMUX |
FEC_ECNTRL_ETHER_EN);
out_be32(fec-fecp-fec_ievent, FEC_ENET_MII);
- out_be32(fec-fecp-fec_mii_speed, fec-mii_speed);
+ clrsetbits_be32(fec-fecp-fec_mii_speed, 0x7E, fec-mii_speed);
new_bus-phy_mask = ~0;
new_bus-irq = kmalloc(sizeof(int) * PHY_MAX_ADDR, GFP_KERNEL);
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC 1/2] Makefile: Never use -fno-omit-frame-pointer
[Sorry for not replying earlier, somehow I missed this mail] On the other hand, *using* -fno-omit-frame-pointer causes gcc to produce buggy code on PowerPC targets. It doesn't cause the problem, it only exposes it. And, of course, only on certain GCC versions. Segher, do you know if all GCC versions that we support for building Linux are behaving the way that GCC manual describe? I believe so, yes. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Support for PCI Express reset type in EEH
By default, EEH does what's known as a hot reset during error recovery of a PCI Express
device. We've found a case where the device needs a fundamental reset to recover
properly. The current PCI error recovery and EEH frameworks do not support this distinction.
The attached patch (courtesy of Richard Lary) implements a reset type callback
that can be used to determine what type of reset a device requires. It is
backwards compatible with all other drivers that implement PCI error recovery
callbacks. Only drivers that require a fundamental reset need to be changed.
So far we're only aware of one driver that has the requirement (qla2xxx). The
patch touches mostly EEH and pseries code, but does require a couple of minor
additions to the overall PCI error recovery framework.
Signed-off-by: Mike Mason mm...@us.ibm.com
--- a/arch/powerpc/include/asm/ppc-pci.h2009-06-09 20:05:27.0
-0700
+++ b/arch/powerpc/include/asm/ppc-pci.h2009-07-13 16:12:31.0
-0700
@@ -90,7 +90,9 @@ int rtas_pci_enable(struct pci_dn *pdn,
*
* Returns a non-zero value if the reset failed.
*/
-int rtas_set_slot_reset (struct pci_dn *);
+#define HOT_RESET 1
+#define FUNDAMENTAL_RESET 3
+int rtas_set_slot_reset (struct pci_dn *, int reset_type);
int eeh_wait_for_slot_status(struct pci_dn *pdn, int max_wait_msecs);
/**
--- a/arch/powerpc/platforms/pseries/eeh.c 2009-06-09 20:05:27.0 -0700
+++ b/arch/powerpc/platforms/pseries/eeh.c 2009-07-13 16:27:27.0
-0700
@@ -666,7 +666,7 @@ rtas_pci_enable(struct pci_dn *pdn, int
/**
* rtas_pci_slot_reset - raises/lowers the pci #RST line
* @pdn pci device node
- * @state: 1/0 to raise/lower the #RST
+ * @state: 1/3/0 to raise hot-reset/fundamental-reset/lower the #RST
*
* Clear the EEH-frozen condition on a slot. This routine
* asserts the PCI #RST line if the 'state' argument is '1',
@@ -742,9 +742,9 @@ int pcibios_set_pcie_reset_state(struct
* Return 0 if success, else a non-zero value.
*/
-static void __rtas_set_slot_reset(struct pci_dn *pdn)
+static void __rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
{
- rtas_pci_slot_reset (pdn, 1);
+ rtas_pci_slot_reset (pdn, reset_type);
/* The PCI bus requires that the reset be held high for at least
* a 100 milliseconds. We wait a bit longer 'just in case'. */
@@ -766,13 +766,13 @@ static void __rtas_set_slot_reset(struct
msleep (PCI_BUS_SETTLE_TIME_MSEC);
}
-int rtas_set_slot_reset(struct pci_dn *pdn)
+int rtas_set_slot_reset(struct pci_dn *pdn, int reset_type)
{
int i, rc;
/* Take three shots at resetting the bus */
for (i=0; i3; i++) {
- __rtas_set_slot_reset(pdn);
+ __rtas_set_slot_reset(pdn, reset_type);
rc = eeh_wait_for_slot_status(pdn, PCI_BUS_RESET_WAIT_MSEC);
if (rc == 0)
--- a/arch/powerpc/platforms/pseries/eeh_driver.c 2009-07-13
14:25:24.0 -0700
+++ b/arch/powerpc/platforms/pseries/eeh_driver.c 2009-07-13
16:39:16.0 -0700
@@ -115,6 +115,34 @@ static void eeh_enable_irq(struct pci_de
/* --- */
/**
+ * eeh_query_reset_type - query each device driver for reset type
+ *
+ * Query each device driver for special reset type if required
+ * merge the device driver responses. Cumulative response
+ * passed back in userdata.
+ */
+
+static int eeh_query_reset_type(struct pci_dev *dev, void *userdata)
+{
+ enum pci_ers_result rc, *res = userdata;
+ struct pci_driver *driver = dev-driver;
+
+ if (!driver)
+ return 0;
+
+ if (!driver-err_handler ||
+ !driver-err_handler-reset_type)
+ return 0;
+
+ rc = driver-err_handler-reset_type (dev);
+
+ /* A driver that needs a special reset trumps all others */
+ if (rc == PCI_ERS_RESULT_FUNDAMENTAL_RESET ) *res = rc;
+
+ return 0;
+}
+
+/**
* eeh_report_error - report pci error to each device driver
*
* Report an EEH error to each device driver, collect up and
@@ -282,9 +310,12 @@ static int eeh_report_failure(struct pci
* @pe_dn: pointer to a Partionable Endpoint device node.
*This is the top-level structure on which pci
*bus resets can be performed.
+ *
+ * reset_type: some devices may require type other than default hot reset.
*/
-static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus)
+static int eeh_reset_device (struct pci_dn *pe_dn, struct pci_bus *bus,
+int reset_type)
{
struct device_node *dn;
int cnt, rc;
@@ -298,7 +329,7 @@ static int eeh_reset_device (struct pci_
/* Reset the pci controller. (Asserts RST#; resets config space).
* Reconfigure bridges and devices. Don't try to bring the system
* up if the reset failed for some reason. */
- rc = rtas_set_slot_reset(pe_dn);
+ rc =
proper way to reserve a chunk of memory at the top of the kernel?
I have a powerpc board with 512BM of memory. The BIOS has a chunk of memory at the top end of physical memory which it does not zero out over a reboot. What's the proper way to tell linux that this chunk of physical memory should be ignored (so that we can access it later without worrying that Linux will try to allocate it)? Should I be calling lmb_reserve(lmb_end_of_DRAM() - size, size); in early_reserve_mem() or is there a better mechanism? For comparison, in an older kernel this was done in set_phys_avail(), by calling mem_pieces_remove(phys_avail, total_lowmem - size, size, 1); Thanks, Chris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
-Anton Vorontsov avoront...@ru.mvista.com skrev: - Till: Joakim Tjernlund joakim.tjernl...@transmode.se Från: Anton Vorontsov avoront...@ru.mvista.com Datum: 07/14/2009 00:20 Kopia: David Brownell dbrown...@users.sourceforge.net, linux-ker...@vger.kernel.org, linuxppc-...@ozlabs.org Ärende: Re: [PATCH 0/2] Setting GPIOs simultaneously On Mon, Jul 13, 2009 at 09:59:54PM +0200, Joakim Tjernlund wrote: [...] While being at it, the reason for me needing this is that the spi_mpc83xx driver was recently converted to a OF only driver so I have no way of defining my own CS function anymore. While OF is good I don't feel that OF drivers should block the native method, OF should be a layer on top of the native methods. Um, I don't get it. You have a mux, which is a sort of GPIO controller. All you need to do is to write of-gpio-mux driver, that will get all the needed gpios from the underlaying GPIO controller. Well, I already have a mux controller that is using the native spi methods. I don't want to write a new one, far more complicated than what I got now. While the OF system is very powerful and flexible I still think that one should be able to use native SPI methods too. Why can they not co-exist? I strongly believe that they can. You just need to post patches so that we could see them, and maybe discuss how to do things more generic. But if making things generic will be too hard (see below), I don't think anybody will object applying a non-generic solution (even permitting legacy bindings in the spi_8xxx driver). But any users of the legacy bindings should be in-tree. ehh, it was working until you made it OF only. Why do call the native way legacy? It is the method all non OF arch uses. In the device tree it'll look like this: I must admit that I just started to look at the GPIO subsystem, but I do wonder if mpc83xx_spi_cs_control() can do this muxing without any change. Very good example BTW. Well, there is one caveat: the GPIOs aren't independent, so thinking about it more, I believe we should now discuss chip-select framework, not gpio controllers (it could be that using gpio controllers for this purpose wasn't that good idea). http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg34738.html ^^^ I'm dreaming about this framework. I.e. true addressing for chip-selects. :-) This is probably needed to support most SPI users out there, but until such framework is in place I think the native methods need to stay, right? As is now, SPI has regressed w.r.t earlier releases. Jocke BTW, I will be offline for a few days as of now. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
On Tue, Jul 14, 2009 at 11:20:13PM +0200, Joakim Tjernlund wrote: [...] But any users of the legacy bindings should be in-tree. ehh, it was working until you made it OF only. Why do call the native way legacy? It is the method all non OF arch uses. It's legacy because there are no in-tree users anymore. Nowadays we're trying to pass all needed information via OF, and we're trying to avoid ugly platform-dependant hacks. Your SPI scheme can be easily described via OF, but sure, it's hard to implement it with the current SPI/OF subsystem. [...] http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg34738.html ^^^ I'm dreaming about this framework. I.e. true addressing for chip-selects. :-) This is probably needed to support most SPI users out there, but until such framework is in place I think the native methods need to stay, right? I'm not the right person to ask. I can only express my opinions. The maintainer make final decision. But if you ask for my opinion, I don't think that they should stay unless we'll see a user in the mainline. As is now, SPI has regressed w.r.t earlier releases. Yes and no. Yes, it has regressed for out-of-tree code, and no, I don't feel sorry about that. :-) -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FTRACE] Enabling function_graph causes OOPS
On Tue, 14 Jul 2009, Sachin Sant wrote: While enabling function_graph tracer on a Power6 box, machine crashed with following trace. Kernel version is 2.6.31-rc3. Thanks, I've seen issues with my PPC box and function graph, but the bugs were also caused by other changes. I'll boot up my PPC64 box and see if I see the same issues you have. -- Steve :/debug/tracing # echo function_graph current_tracer :/debug/tracing # cat current_tracer function_graph :/debug/tracing # echo 1 tracing_enabled cpu 0x0: Vector: 300 (Data Access) at [c0003eb86de0] pc: c0008f30: .mod_return_to_handler+0x2c/0x64 lr: c0008f04: .mod_return_to_handler+0x0/0x64 sp: c0003eb87060 msr: 80009032 dar: 8 dsisr: 4000 current = 0xc0003e83c080 paca= 0xc0ff2400 pid = 2700, comm = sshd enter ? for help [c0003eb870d0] c0008f04 .mod_return_to_handler+0x0/0x64 [c0003eb871a0] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87290] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87330] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb873e0] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87470] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87500] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87640] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87730] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87830] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb878d0] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87a00] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87b30] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87cd0] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87d80] c0008ed0 .return_to_handler+0x0/0x34 [c0003eb87e30] c0008ed0 .return_to_handler+0x0/0x34 --- Exception: c01 (System Call) at 0fffb640a8f8 SP (fffe5b9b960) is in userspace 0:mon di c0008f04 c0008f04 f881ffe0 std r4,-32(r1) c0008f08 f861ffe8 std r3,-24(r1) c0008f0c f841fff0 std r2,-16(r1) c0008f10 fbe1fff8 std r31,-8(r1) c0008f14 7c3f0b78 mr r31,r1 c0008f18 f821ff91 stdur1,-112(r1) c0008f1c 3c80 lis r4,0 c0008f20 6084 ori r4,r4,0 c0008f24 788407c6 rldicr r4,r4,32,31 c0008f28 6484 orisr4,r4,0 c0008f2c 6084 ori r4,r4,0 c0008f30 e8440008 ld r2,8(r4) ^ PC points to this ^^^ c0008f34 48123431 bl c012c364# .ftrace_return_to_handler+0x0/0x110 c0008f38 6000 nop c0008f3c 7c6803a6 mtlrr3 c0008f40 e821 ld r1,0(r1) 0:xmon r R00 = c0008f04 R16 = 0fffb741d6a0 R01 = c0003ea4b7e0 R17 = 0fffb7406c38 R02 = d10bec80 R18 = c0003de41838 R03 = R19 = f000 R04 = R20 = c0003cfc8c80 R05 = 6600 R21 = c0003ea4bdf8 R06 = 10bf R22 = c0003ea4bba8 R07 = R23 = 0fff8eb6 R08 = R24 = f000 R09 = 80010021c740 R25 = 80010300 R10 = 00ff R26 = ffe0 R11 = 80010021c760 R27 = 0009 R12 = 0002 R28 = c0006f85 R13 = c0ff2400 R29 = 0002 R14 = R30 = d10bd9c8 R15 = effdff68 R31 = c0003ea4b850 pc = c0008f30 .mod_return_to_handler+0x2c/0x64 lr = c0008f04 .mod_return_to_handler+0x0/0x64 msr = 80009032 cr = 24000442 ctr = 800f6d68 xer = 0020 trap = 300 dar = 0008 dsisr = 4000 0:xmon Following tracers are supported by the kernel. :/debug/tracing # cat available_tracers function_graph function sched_switch nop Other tracers function and sched_switch work fine. Having problem only with function_graph. Have attached the .config. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
riscwatch shows up core status UNKNOWN for 970mp ppc processor
Hello I am newbie to RISCWatch and debugging using JTAG interface .I want to debug Linux Kernel on target board using jtag interface provided on board. To debug 970MP dual core ppc processor on traget board, I installed RISCWatch software on my window host. My Setup: -- Host --(over ethernet)-- RISCWatch 13H6423 --(jtag interface)-- 970MP Processor I am able to detect two core on target 970MP processor but it shows both cores as `UNKNOWN` . I have no idea, why riscwatch shows up status of both cores as UNKNOWN? I would like to mention: - 1) After attaching JTAG cable switching on riscwatch box, powered cycle was done on the target board and restart RISCWatch. But still core status is shown `UNKNOWN` 2) For PVR value 0x00440101, I used `REV = 1' in rwppc.env file. Correct us if I am wrong. 3) I am able to ping RISCWatch 13H6423 from host system. 4) When I reset target board, target status changes from UNKNOWN to HALTED and HALTED to UNKNOWN I noticed that PVR register value is 0x00440101. I am not sure if this confirms that revision of the processor(970mp) is 1. Please find the rwppc.env file (C:\Program Files\RISCWatch\rwppc.env) that I configured: PROC = 970MP REV = 1 TARGET_TYPE = jtag_eth TARGET_NAME = 192.168.10.5 RWPPC_DIR = . SEARCH_PATH = . LOG_FILE_DIR = . SAVE_LAYOUT = no PRD_FILE = rwppc.prd Please find board information: -- KAT2000 970MP (1.0)= boardinfo board config data version: 1.0 processor name : 970MP processor PVR value : 0x00440101 timer clock frequency: 11250 total SDRAM memory : 4096MB SDRAM frequency : 5 system clk frequency (Hz): 22500 CPU frequency: 18 CPU frequency ind. est. : 181200 CPU to EI speed ratio: 2:1 frequency scaling divider: 1 serial clk frequency : 1843200 HID0 value : 001100818000 HID1 value : fd3c2000 HID4 value : 0010 HID5 value : 0080 SDR1 value : 00d2 PIR value : Ethernet hardware addr 0 : RISCWatch log: -- 12:37:18 - RISCWatch program start 12:37:18 - RISCWatch v7.1 for Windows XP 12:37:18 - Current directory: C:\Program Files\RISCWatch 12:37:18 - Environment file: RWPPC.ENV 12:37:18 - RWPPC_DIR = . 12:37:18 - TARGET_TYPE = JTAG_Ethernet 12:37:18 - TARGET_NAME = 192.168.10.5 12:37:18 - Requested Processor 970MPRev1:CORE1 12:37:18 - Requested Processor 970MPRev1:CORE2 12:37:18 - Unable to get port number for jtag_eth service, using 6470 default 12:37:30 - Configuring probe 12:37:30 - cf default; jtagch a32,a32 12:37:31 - HPE8130A Series Emulation System 12:37:31 - Version: A.01.20 04Apr02 Unreleased 12:37:31 - Location: Generics 12:37:31 - HPEGPUL PowerPC 970 JTAG Emulator 12:37:31 - Version: A.00.I0 22Jul08 13:48 Proto 12:37:31 - WARNING : Could not read processor status, slowing JTAG clock and retrying 12:37:31 - ERROR : bad status received, see README for possible causes 12:37:36 - Starting MPS mode 12:43:18 - STATUS : CORE1 status changed from UNKNOWN to HALTED 12:43:18 - STATUS : CORE2 status changed from UNKNOWN to HALTED Note--- Status become HALTED because I reset target board 12:43:19 - ERROR : CORE1 status changed from HALTED to UNKNOWN 12:43:19 - ERROR : CORE2 status changed from HALTED to UNKNOWN Regards, Anil ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
