* [PATCH] powerpc: Fix CPM2 SCC1 clock initialization.
From: Laurent Pinchart @ 2008-04-02 14:46 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
A missing break statement in a switch caused cpm2_clk_setup() to initialize
SCC2 instead of SCC1. This patch fixes the bug.
Signed-off-by: Laurent Pinchart <laurentp@cse-semaphore.com>
---
arch/powerpc/sysdev/cpm2.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 57ed1a4..7478e81 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -246,6 +246,7 @@ int cpm2_clk_setup(enum cpm_clk_target target, int clock, int mode)
case CPM_CLK_SCC1:
reg = &im_cpmux->cmx_scr;
shift = 24;
+ break;
case CPM_CLK_SCC2:
reg = &im_cpmux->cmx_scr;
shift = 16;
--
1.5.0
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: ARCH=ppc vs powerpc
From: Guillaume Dargaud @ 2008-04-02 14:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <0cf501c894cb$c73dfee0$f52f9e86@LPSC0173W>
Sorry, although it's related to linuxppc, I intended to post this question
to the buildroot mailing list.
--
Guillaume Dargaud
http://www.gdargaud.net/
^ permalink raw reply
* [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
From: Stefan Roese @ 2008-04-02 15:12 UTC (permalink / raw)
To: linuxppc-dev
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking whether the PCIe port is already configured as
root-complex or as endpoint. This has been done previously in U-Boot and
can be configured there dynamically by setting the "pcie_mode"
environment variable (reboot necessary of course). Here an example:
pcie_mode = 'RP:RP:EP'
Port 0 & 1 are configured as root-complex and port 2 as endpoint.
This mode will now be used in the Linux driver too.
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should probably be configurable via a dts property.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 133 +++++++++++++++++++++++++++-----------
1 files changed, 96 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index d183b83..013fd05 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -563,6 +563,18 @@ struct ppc4xx_pciex_hwops
static struct ppc4xx_pciex_hwops *ppc4xx_pciex_hwops;
+static int is_endpoint(struct ppc4xx_pciex_port *port)
+{
+ u32 val;
+
+ val = mfdcri(SDR0, port->sdr_base + PESDRn_DLPSET);
+
+ if (((val >> 20) & 0xf) == PTYPE_LEGACY_ENDPOINT)
+ return 1;
+ else
+ return 0;
+}
+
#ifdef CONFIG_44x
/* Check various reset bits of the 440SPe PCIe core */
@@ -1400,28 +1412,59 @@ static void __init ppc4xx_configure_pciex_PIMs(struct ppc4xx_pciex_port *port,
resource_size_t size = res->end - res->start + 1;
u64 sa;
- /* Calculate window size */
- sa = (0xffffffffffffffffull << ilog2(size));;
- if (res->flags & IORESOURCE_PREFETCH)
- sa |= 0x8;
+ if (port->endpoint) {
+ resource_size_t ep_addr = 0;
+ resource_size_t ep_size = 32 << 20;
- out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
- out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+ /* Currently we map a fixed 64MByte window to PLB address
+ * 0 (SDRAM). This should probably be configurable via a dts
+ * property.
+ */
+
+ /* Calculate window size */
+ sa = (0xffffffffffffffffull << ilog2(ep_size));;
+
+ /* Setup BAR0 */
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa) |
+ PCI_BASE_ADDRESS_MEM_TYPE_64);
- /* The setup of the split looks weird to me ... let's see if it works */
- out_le32(mbase + PECFG_PIM0LAL, 0x00000000);
- out_le32(mbase + PECFG_PIM0LAH, 0x00000000);
- out_le32(mbase + PECFG_PIM1LAL, 0x00000000);
- out_le32(mbase + PECFG_PIM1LAH, 0x00000000);
- out_le32(mbase + PECFG_PIM01SAH, 0xffff0000);
- out_le32(mbase + PECFG_PIM01SAL, 0x00000000);
+ /* Disable BAR1 & BAR2 */
+ out_le32(mbase + PECFG_BAR1MPA, 0);
+ out_le32(mbase + PECFG_BAR2HMPA, 0);
+ out_le32(mbase + PECFG_BAR2LMPA, 0);
+
+ out_le32(mbase + PECFG_PIM01SAH, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_PIM01SAL, RES_TO_U32_LOW(sa));
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(ep_addr));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(ep_addr));
+ } else {
+ /* Calculate window size */
+ sa = (0xffffffffffffffffull << ilog2(size));;
+ if (res->flags & IORESOURCE_PREFETCH)
+ sa |= 0x8;
+
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+
+ /* The setup of the split looks weird to me ... let's see
+ * if it works
+ */
+ out_le32(mbase + PECFG_PIM0LAL, 0x00000000);
+ out_le32(mbase + PECFG_PIM0LAH, 0x00000000);
+ out_le32(mbase + PECFG_PIM1LAL, 0x00000000);
+ out_le32(mbase + PECFG_PIM1LAH, 0x00000000);
+ out_le32(mbase + PECFG_PIM01SAH, 0xffff0000);
+ out_le32(mbase + PECFG_PIM01SAL, 0x00000000);
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
+ }
/* Enable inbound mapping */
out_le32(mbase + PECFG_PIMEN, 0x1);
- out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
- out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
-
/* Enable I/O, Mem, and Busmaster cycles */
out_le16(mbase + PCI_COMMAND,
in_le16(mbase + PCI_COMMAND) |
@@ -1436,13 +1479,6 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
int primary = 0, busses;
void __iomem *mbase = NULL, *cfg_data = NULL;
- /* XXX FIXME: Handle endpoint mode properly */
- if (port->endpoint) {
- printk(KERN_WARNING "PCIE%d: Port in endpoint mode !\n",
- port->index);
- return;
- }
-
/* Check if primary bridge */
if (of_get_property(port->node, "primary", NULL))
primary = 1;
@@ -1502,12 +1538,14 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
port->hose = hose;
mbase = (void __iomem *)hose->cfg_addr;
- /*
- * Set bus numbers on our root port
- */
- out_8(mbase + PCI_PRIMARY_BUS, hose->first_busno);
- out_8(mbase + PCI_SECONDARY_BUS, hose->first_busno + 1);
- out_8(mbase + PCI_SUBORDINATE_BUS, hose->last_busno);
+ if (!port->endpoint) {
+ /*
+ * Set bus numbers on our root port
+ */
+ out_8(mbase + PCI_PRIMARY_BUS, hose->first_busno);
+ out_8(mbase + PCI_SECONDARY_BUS, hose->first_busno + 1);
+ out_8(mbase + PCI_SUBORDINATE_BUS, hose->last_busno);
+ }
/*
* OMRs are already reset, also disable PIMs
@@ -1531,14 +1569,26 @@ static void __init ppc4xx_pciex_port_setup_hose(struct ppc4xx_pciex_port *port)
* and device IDs into it. Those are the same bogus one that the
* initial code in arch/ppc add. We might want to change that.
*/
- out_le16(mbase + 0x200, 0xaaa0 + port->index);
- out_le16(mbase + 0x202, 0xbed0 + port->index);
+ if (!port->endpoint) {
+ out_le16(mbase + 0x200, 0xaaa0 + port->index);
+ out_le16(mbase + 0x202, 0xbed0 + port->index);
- /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
- out_le32(mbase + 0x208, 0x06040001);
+ /* Set Class Code to PCI-PCI bridge and Revision Id to 1 */
+ out_le32(mbase + 0x208, 0x06040001);
+
+ printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
+ port->index);
+ } else {
+ out_le16(mbase + 0x200, 0xeee0 + port->index);
+ out_le16(mbase + 0x202, 0xfed0 + port->index);
+
+ /* Set Class Code to Processor/PPC */
+ out_le32(mbase + 0x208, 0x0b200001);
+
+ printk(KERN_INFO "PCIE%d: successfully set as endpoint\n",
+ port->index);
+ }
- printk(KERN_INFO "PCIE%d: successfully set as root-complex\n",
- port->index);
return;
fail:
if (hose)
@@ -1586,8 +1636,17 @@ static void __init ppc4xx_probe_pciex_bridge(struct device_node *np)
}
port->sdr_base = *pval;
- /* XXX Currently, we only support root complex mode */
- port->endpoint = 0;
+ /* Check whether the PCIe port is already configured as root-complex
+ * or as endpoint. This has been done previously in U-Boot and can
+ * be configured there dynamically by setting the "pcie_mode"
+ * environment variable (reboot necessary of course). Here an example:
+ *
+ * pcie_mode = 'RP:RP:EP'
+ *
+ * Port 0 & 1 are configured as root-complex and port 2 as endpoint.
+ * This mode will now be used in the Linux driver too.
+ */
+ port->endpoint = is_endpoint(port);
/* Fetch config space registers address */
if (of_address_to_resource(np, 0, &port->cfg_space)) {
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
From: Stefan Roese @ 2008-04-02 15:16 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1207149149-17107-1-git-send-email-sr@denx.de>
On Wednesday 02 April 2008, Stefan Roese wrote:
> This patch adds basic endpoint support to the 4xx PCIe driver.
This should have been an RFC. Sorry I missed adding it to the subject.
Best regards,
Stefan
^ permalink raw reply
* RE: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: John Linn @ 2008-04-02 15:23 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: git, linuxppc-embedded
In-Reply-To: <87lk3w8u00.fsf@macbook.be.48ers.dk>
Hi Peter,
We added arch/ppc support because it was the easiest path for us. We
realize it's going away soon in the mainline.
We are working on getting arch/powerpc more mature for both the 405 and
the 440 as we do believe this is the future for powerpc.
Thanks,
John
-----Original Message-----
From: Peter Korsgaard [mailto:jacmet@gmail.com] On Behalf Of Peter
Korsgaard
Sent: Wednesday, April 02, 2008 3:51 AM
To: John Linn
Cc: linuxppc-embedded@ozlabs.org; git
Subject: Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
>>>>> "John" =3D=3D John Linn <John.Linn@xilinx.com> writes:
John> I pushed PowerPC 440 support to the Xilinx Git server with
John> support for ppc arch and with powerpc arch support coming in
John> the near future.
Neat, but why have you added arch/ppc support? It's supposed to go
away pretty much by the time the hardware gets in the hand of
developers.
--=20
Bye, Peter Korsgaard
^ permalink raw reply
* RE: Virtex V5FX PPC 440 Support In Xilinx Git Tree
From: Stephen Neuendorffer @ 2008-04-02 16:34 UTC (permalink / raw)
To: John Linn, Peter Korsgaard, Grant Likely; +Cc: git, linuxppc-embedded
In-Reply-To: <689CB232690D8D4E97DA6C76DA098E6C05FC43ED@XCO-EXCHVS1.xlnx.xilinx.com>
I've just pushed support for generating device trees for the ppc440 in
V5FXT up to git.xilinx.com.
The most obvious difference is that the PPC440 block contains not only
the PPC440 core, but also an interconnect block, subsuming part of the
'multi-ported' functionality of the MPMC. In order to have a relatively
straightforward mapping between blocks in the EDK design and nodes in
the dts, I've represented this as shown below. Note that unlike the
MPMC, the dma ports are controlled through DCR (which is part of the
point of the recent dcr patches). I've done some preliminary testing
using some hacked together platform support code and we'll update this
based on the 405 code soon.
Steve
/ {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatible =3D "xlnx,virtex";
dcr-parent =3D <&ppc440_virtex5_0>;
model =3D "testing";
chosen {
bootargs =3D "root=3D/dev/xsysace/disc0/part2";
} ;
cpus {
#address-cells =3D <1>;
#cpus =3D <1>;
#size-cells =3D <0>;
ppc440_virtex5_0: cpu@0 {
#address-cells =3D <1>;
#size-cells =3D <1>;
clock-frequency =3D <17d78400>;
compatible =3D "PowerPC,440", "ibm,ppc440";
d-cache-line-size =3D <20>;
d-cache-line-size =3D <20>;
d-cache-size =3D <8000>;
dcr-access-method =3D "native";
dcr-controller ;
device_type =3D "cpu";
i-cache-line-size =3D <20>;
i-cache-size =3D <8000>;
model =3D "PowerPC,440";
reg =3D <0>;
timebase-frequency =3D <17d78400>;
DMA0: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 5 2 6 2 >;
} ;
DMA1: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
} ;
DMA2: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
} ;
DMA3: sdma@1010000 {
compatible =3D "xlnx,ll-dma-1.00.a";
dcr-reg =3D < 1010000 11 >;
} ;
} ;
} ;
plb_v46_cfb_0: plb@0 {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatible =3D "xlnx,plb-v46-1.00.a";
ranges ;
iic_bus: i2c@d0020000 {
compatible =3D "xlnx,xps-iic-1.00.a";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 7 2 >;
reg =3D < d0020000 200 >;
xlnx,clk-freq =3D <5f5e100>;
xlnx,family =3D "virtex5";
xlnx,gpo-width =3D <1>;
xlnx,iic-freq =3D <186a0>;
xlnx,ten-bit-adr =3D <0>;
} ;
leds_8bit: gpio@d0010200 {
compatible =3D "xlnx,xps-gpio-1.00.a";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 1 2 >;
reg =3D < d0010200 200 >;
xlnx,all-inputs =3D <0>;
xlnx,all-inputs-2 =3D <0>;
xlnx,dout-default =3D <0>;
xlnx,dout-default-2 =3D <0>;
xlnx,family =3D "virtex5";
xlnx,gpio-width =3D <8>;
xlnx,interrupt-present =3D <1>;
xlnx,is-bidir =3D <1>;
xlnx,is-bidir-2 =3D <1>;
xlnx,is-dual =3D <0>;
xlnx,tri-default =3D <ffffffff>;
xlnx,tri-default-2 =3D <ffffffff>;
} ;
ll_temac_0: xps-ll-temac@91200000 {
#address-cells =3D <1>;
#size-cells =3D <1>;
compatible =3D "xlnx,compound";
ethernet@91200000 {
compatible =3D "xlnx,xps-ll-temac-1.00.b";
device_type =3D "network";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 4 2 >;
llink-connected =3D <&DMA0>;
local-mac-address =3D [ 00 00 00 00 00 00
];
reg =3D < 91200000 40 >;
xlnx,bus2core-clk-ratio =3D <1>;
xlnx,phy-type =3D <1>;
xlnx,phyaddr =3D <1>;
xlnx,rxcsum =3D <0>;
xlnx,rxfifo =3D <4000>;
xlnx,temac-type =3D <0>;
xlnx,txcsum =3D <0>;
xlnx,txfifo =3D <4000>;
} ;
} ;
opb_intc_0: interrupt-controller@d0020200 {
#interrupt-cells =3D <2>;
compatible =3D "xlnx,xps-intc-1.00.a";
interrupt-controller ;
reg =3D < d0020200 20 >;
xlnx,num-intr-inputs =3D <8>;
} ;
plb_bram_if_cntlr_0: xps-bram-if-cntlr@ffff0000 {
compatible =3D "xlnx,xps-bram-if-cntlr-1.00.a";
reg =3D < ffff0000 10000 >;
xlnx,family =3D "virtex5";
} ;
plb_bram_if_cntlr_1: xps-bram-if-cntlr@eee00000 {
compatible =3D "xlnx,xps-bram-if-cntlr-1.00.a";
reg =3D < eee00000 2000 >;
xlnx,family =3D "virtex5";
} ;
rs232_uart_0: serial@d0000000 {
clock-frequency =3D "";
compatible =3D "xlnx,xps-uart16550-1.00.a";
current-speed =3D <2580>;
device_type =3D "serial";
interrupt-parent =3D <&opb_intc_0>;
interrupts =3D < 0 2 >;
reg =3D < d0000000 2000 >;
reg-offset =3D <3>;
reg-shift =3D <2>;
xlnx,family =3D "virtex5";
xlnx,has-external-rclk =3D <0>;
xlnx,has-external-xin =3D <1>;
xlnx,is-a-16550 =3D <1>;
} ;
sysace_compactflash: sysace@d0030100 {
compatible =3D "xlnx,xps-sysace-1.00.a";
reg =3D < d0030100 80 >;
xlnx,family =3D "virtex5";
xlnx,mem-width =3D <10>;
} ;
} ;
ppc440mc_ddr2_0: memory@0 {
device_type =3D "memory";
reg =3D < 0 20000000 >;
} ;
} ;
> -----Original Message-----
> From: John Linn
> Sent: Wednesday, April 02, 2008 8:24 AM
> To: Peter Korsgaard
> Cc: linuxppc-embedded@ozlabs.org; git
> Subject: RE: Virtex V5FX PPC 440 Support In Xilinx Git Tree
>=20
> Hi Peter,
>=20
> We added arch/ppc support because it was the easiest path for us. We
realize it's going away soon in
> the mainline.
>=20
> We are working on getting arch/powerpc more mature for both the 405
and the 440 as we do believe this
> is the future for powerpc.
>=20
> Thanks,
> John
>=20
>=20
>=20
> -----Original Message-----
> From: Peter Korsgaard [mailto:jacmet@gmail.com] On Behalf Of Peter
Korsgaard
> Sent: Wednesday, April 02, 2008 3:51 AM
> To: John Linn
> Cc: linuxppc-embedded@ozlabs.org; git
> Subject: Re: Virtex V5FX PPC 440 Support In Xilinx Git Tree
>=20
> >>>>> "John" =3D=3D John Linn <John.Linn@xilinx.com> writes:
>=20
> John> I pushed PowerPC 440 support to the Xilinx Git server with
> John> support for ppc arch and with powerpc arch support coming in
> John> the near future.
>=20
> Neat, but why have you added arch/ppc support? It's supposed to go
> away pretty much by the time the hardware gets in the hand of
> developers.
>=20
> --
> Bye, Peter Korsgaard
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-04-02 16:42 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cel, cbe-oss-dev, linux-kernel
In-Reply-To: <200804020721.15861.arnd@arndb.de>
On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> On Tuesday 25 March 2008, Carl Love wrote:
> > This patch fixes a bug in the code that records the SPU data and
> > context switches. The buffer_mutex lock must be held when the
> > kernel is adding data to the buffer between the kernel and the
> > OProfile daemon. The lock is not being held in the current code
> > base. This patch fixes the bug using work queues. The data to
> > be passed to the daemon is caputured by the interrupt handler.
> > The workqueue function is invoked to grab the buffer_mutex lock
> > and add the data to the buffer.
>
> So what was the exact bug you're fixing with this? There was no
> buffer_mutex before, so why do you need it now? Can't this be a
> spinlock so you can get it from interrupt context instead of
> using a workqueue?
The generic OProfile code defines a mutex lock, called buffer_mutex, to
protect the kernel/daemon data buffer from being writen by the kernal
and simultaneously read by the Daemon. When adding a PPU sample the
oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is
called from the interrupt context to request the sample be stored. The
generic oprofile code takes care of passing the data to a non interrupt
context where the mutex lock is held and the necessary sequence of data
is written into the kernel/daemon data buffer. However, OProfile does
not have any built in functions for handling the SPU. Hence, we have to
implement the code to capture the data in the interrupt context, pass it
to a non interrupt context and put it into the buffer. This was not
done correctly in the original implementation. Specifically, the mutex
lock was not being held.
Writing data to the OProfile buffer consists of a sequence of items.
For example when writing an SPU entry, first comes the escape code so
the daemon knows this is a new entry. The next item is the SPU context
switch code which says the data which will follow is the information
about a new context. There is a different code to identify the data as
an address sample. Finally the data about the SPU context switch is
entered into the buffer. The issue is the OProfile daemon is read all
of the entire sequence of items then process the data. Without the
mutex lock, the daemon may read part of the sequence try to process it
before everything is written into the buffer. When the daemon reads
again, it doesn't see the escape code as the first item and isn't smart
enough to realize it is part of a previous sequence. The generic
OProfile code defines the mutex lock and calls it buffer_mutex. The
OProfile kernel/daemon API uses the mutex lock. The mutex lock can only
be held in a non interrupt context. The current implementation uses a
spin lock to make sure the kernel writes each sequence if items into the
buffer but since the API does not use a spin lock we have no way to
prevent the daemon from reading the buffer until the entire sequence of
items has been written to the buffer. Hence the need to hold the
buffer_mutex lock which prevents the daemon from accessing the buffer.
>
> > Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > ===================================================================
> > --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> > +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > @@ -16,6 +16,7 @@
> > #include <linux/smp.h>
> > #include <linux/slab.h>
> > #include <asm/cell-pmu.h>
> > +#include <linux/workqueue.h>
> > #include "pr_util.h"
> >
>
> Please keep #include statements in alphabetical order, with all linux/ files
> before the asm/ files.
>
> > #define TRACE_ARRAY_SIZE 1024
> > @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
> >
> > #define SPU_PC_MASK 0xFFFF
> >
> > +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> > + * between the kernel and the daemon. The SPU code needs to use the buffer
> > + * to ensure that the kernel SPU writes complete as a single block before
> > + * being consumed by the daemon.
> > + */
> > +extern struct mutex buffer_mutex;
> > +
> > static DEFINE_SPINLOCK(sample_array_lock);
> > unsigned long sample_array_lock_flags;
> >
> > +struct work_struct spu_record_wq;
> > +extern struct workqueue_struct *oprofile_spu_wq;
> > +
> > void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int cycles_reset)
> > {
> > unsigned long ns_per_cyc;
>
> Never put extern statements in the implementation, they describe the
> interface between two parts of the code and should be inside of a
> common header.
>
> Why do you want to have your own workqueue instead of using the
> global one?
>
> > @@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
> > return entry;
> > }
> >
> > -
> > -static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > -{
> > - ktime_t kt;
> > +static void profile_spus_record_samples (struct work_struct *ws) {
> > + /* This routine is called via schedule_work() to record the
> > + * spu data. It must be run in a normal kernel mode to
> > + * grab the OProfile mutex lock.
> > + */
> > int cpu, node, k, num_samples, spu_num;
> >
> > - if (!spu_prof_running)
> > - goto stop;
> > + mutex_lock(&buffer_mutex);
> >
> > for_each_online_cpu(cpu) {
> > if (cbe_get_hw_thread_id(cpu))
> > @@ -170,6 +181,20 @@ static enum hrtimer_restart profile_spus
> > smp_wmb(); /* insure spu event buffer updates are written */
> > /* don't want events intermingled... */
> >
> > + mutex_unlock(&buffer_mutex);
> > +}
> > +
> > +static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > +{
> > + ktime_t kt;
> > +
> > +
> > + if (!spu_prof_running)
> > + goto stop;
> > +
> > + /* schedule the funtion to record the data */
> > + schedule_work(&spu_record_wq);
> > +
> > kt = ktime_set(0, profiling_interval);
> > if (!spu_prof_running)
> > goto stop;
>
> This looks like you want to use a delayed_work rather than building your
> own out of hrtimer and work. Is there any point why you want to use
> an hrtimer?
The current implementation uses the hrtimer to schedule when to read the
trace buffer the next time. This patch does not change how the
scheduling of the buffer reads is done. Yes, you could change the
implementation to use workqueues instead. If you feel that it is better
to use the workqueue then we could make that change. Not sure that
making that change in this bug fix patch is appropriate. I would need
to create a second patch for that change.
>
> > -static DEFINE_SPINLOCK(buffer_lock);
> > +extern struct mutex buffer_mutex;
> > +extern struct workqueue_struct *oprofile_spu_wq;
> > +extern int calls_to_record_switch;
> > +
>
> Again, public interfaces need to go to a header file, and should
> have a name that identifies the interface. "buffer_mutex" is
> certainly not a suitable name for a kernel-wide global variable!
As stated earlier, the generic OProfile code defines the variable
"buffer_mutex". Changing the name in the generic OProfile code is
beyond the scope of this patch.
>
> > static DEFINE_SPINLOCK(cache_lock);
> > static int num_spu_nodes;
> > +
> > int spu_prof_num_nodes;
> > int last_guard_val[MAX_NUMNODES * 8];
> > +int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
> > +
> > +struct spus_profiling_code_data_s {
> > + int num_spu_nodes;
> > + struct work_struct spu_prof_code_wq;
> > +} spus_profiling_code_data;
> > +
> > +struct spu_context_switch_data_s {
> > + struct spu *spu;
> > + unsigned long spu_cookie;
> > + unsigned long app_dcookie;
> > + unsigned int offset;
> > + unsigned long objectId;
> > + int valid_entry;
> > +} spu_context_switch_data;
>
> I don't understand what these variables are really doing, but
> having e.g. just one spu_context_switch_data for all the SPUs
> doesn't seem to make much sense. What happens when two SPUs do
> a context switch at the same time?
This is the data same data that was being put into the event buffer
directly from the interrupt context. We need to store the data that is
only available in the interrupt context so the same data can be put into
the buffer by the work queue function in the non interrupt context.
This is the declaration of the data needed per SPU. Below in the
spu_cntx_sw_data structure, we declare an array of entries so we can
store the switch
>
> > +int calls_to_record_switch = 0;
> > +int record_spu_start_flag = 0;
> > +
> > +struct spus_cntxt_sw_data_s {
> > + int num_spu_nodes;
> > + struct spu_context_switch_data_s spu_data[MAX_NUMNODES * 8];
> > + struct work_struct spu_cntxt_work;
> > +} spus_cntxt_sw_data;
>
> Something is very wrong if you need so many global variables!
>
> > /* Container for caching information about an active SPU task. */
> > struct cached_info {
> > @@ -44,6 +73,8 @@ struct cached_info {
> > struct kref cache_ref;
> > };
> >
> > +struct workqueue_struct *oprofile_spu_wq;
> > +
> > static struct cached_info *spu_info[MAX_NUMNODES * 8];
>
> While you're cleaning this up, I guess the cached_info should
> be moved into a pointer from struct spu as well, instead of
> having this global variable here.
>
> > @@ -375,16 +457,30 @@ int spu_sync_start(void)
> > int k;
> > int ret = SKIP_GENERIC_SYNC;
> > int register_ret;
> > - unsigned long flags = 0;
> >
> > spu_prof_num_nodes = number_of_online_nodes();
> > num_spu_nodes = spu_prof_num_nodes * 8;
> >
> > - spin_lock_irqsave(&buffer_lock, flags);
> > - add_event_entry(ESCAPE_CODE);
> > - add_event_entry(SPU_PROFILING_CODE);
> > - add_event_entry(num_spu_nodes);
> > - spin_unlock_irqrestore(&buffer_lock, flags);
> > + /* create private work queue, execution of work is time critical */
> > + oprofile_spu_wq = create_workqueue("spu_oprofile");
> > +
> > + /* due to a race when the spu is already running stuff, need to
> > + * set a flag to tell the spu context switch to record the start
> > + * before recording the context switches.
> > + */
> > + record_spu_start_flag = 1;
> > +
> > + spus_profiling_code_data.num_spu_nodes = num_spu_nodes;
> > +
> > + /* setup work queue functiion for recording context switch info */
> > + spus_cntxt_sw_data.num_spu_nodes = num_spu_nodes;
> > + for (k = 0; k<(MAX_NUMNODES * 8); k++) {
> > + spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
> > + cnt_swtch_processed_flag[k] = 0;
> > + }
> > +
> > + INIT_WORK(&spus_cntxt_sw_data.spu_cntxt_work,
> > + record_spu_process_switch);
>
> I would guess that you need one work struct per SPU instead of a global
> one, if you want to pass the SPU pointer as an argument.
>
> Arnd <><
^ permalink raw reply
* [PATCH 0/3] [POWERPC] [V2][RFC] of_serial and boot patches introduction
From: John Linn @ 2008-04-02 16:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
I am sending V2 series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
The ePAPR, although not a formal spec yet, proposes allowing reg-shift
for ns16550. We believe this is a reasonable approach and have
implemented it in this patch series.
We've tried to integrate the consensus from the previous comments also.
[v1]
I am sending a series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
I think we have tried to satisfy previous concerns about UARTs which are
non-standard as the Xilinx 16550 is (register spacing and offset).
We would like to have these pulled into 2.6.26.
Thanks,
John
[-- Attachment #2: Type: text/html, Size: 9079 bytes --]
^ permalink raw reply
* [PATCH 0/3] [POWERPC] [V2][RFC] of_serial and boot patches introduction
From: John Linn @ 2008-04-02 16:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 768 bytes --]
I am sending V2 series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
The ePAPR, although not a formal spec yet, proposes allowing reg-shift
for ns16550. We believe this is a reasonable approach and have
implemented it in this patch series.
We've tried to integrate the consensus from the previous comments also.
[v1]
I am sending a series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
I think we have tried to satisfy previous concerns about UARTs which are
non-standard as the Xilinx 16550 is (register spacing and offset).
We would like to have these pulled into 2.6.26.
Thanks,
John
[-- Attachment #2: Type: text/html, Size: 9080 bytes --]
^ permalink raw reply
* [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: John Linn @ 2008-04-02 16:52 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
The of_serial driver queries the current-speed property and attempts
to use it to register the custom_divisor property of the uart_port.
However, if current-speed is not set, then this code will dereference
a bad pointer. The fix is to only set custom_divisor when a
current-speed property appears in the device tree.
Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/serial/of_serial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index a64d858..2efb892 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
| UPF_FIXED_PORT;
port->dev = &ofdev->dev;
- port->custom_divisor = *clk / (16 * (*spd));
+ /* If current-speed was set, then try not to change it. */
+ if (spd)
+ port->custom_divisor = *clk / (16 * (*spd));
return 0;
}
--
1.5.2.1
^ permalink raw reply related
* [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 16:52 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
In-Reply-To: <12071551354058-git-send-email-john.linn@xilinx.com>
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handle the reg-offset
and reg-shift properties to enable this core to be used.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
Documentation/powerpc/booting-without-of.txt | 11 +++++++++++
drivers/serial/of_serial.c | 15 +++++++++++++--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 87f4d84..af112d9 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model.
differ between different families. May be
'virtex2p', 'virtex4', or 'virtex5'.
+ iv) Xilinx Uart 16550
+
+ Xilinx UART 16550 devices are very similar to the NS16550 such that they
+ use the ns16550 binding with properties to specify register spacing and
+ an offset from the base address.
+
+ Requred properties:
+ - clock-frequency : Frequency of the clock input
+ - reg-offset : A value of 3 is required
+ - reg-shift : A value of 2 is required
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2efb892..af9ed48 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
{
struct resource resource;
struct device_node *np = ofdev->node;
- const unsigned int *clk, *spd;
+ const unsigned int *clk, *spd, *reg_offset, *reg_shift;
int ret;
memset(port, 0, sizeof *port);
@@ -48,7 +48,18 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
}
spin_lock_init(&port->lock);
- port->mapbase = resource.start;
+
+ reg_offset = of_get_property(np, "reg-offset", NULL);
+ reg_shift = of_get_property(np, "reg-shift", NULL);
+
+ if (!reg_offset)
+ port->mapbase = resource.start;
+ else
+ port->mapbase = resource.start + *reg_offset;
+
+ if (reg_shift)
+ port->regshift = *reg_shift;
+
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
port->type = type;
--
1.5.2.1
^ permalink raw reply related
* [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 16:52 UTC (permalink / raw)
To: linuxppc-dev, grant.likely; +Cc: John Linn
In-Reply-To: <12071551351007-git-send-email-john.linn@xilinx.com>
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based adressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the ns16550 driver to use the reg-offset property
so that the Xilinx UART 16550 can be used with it. The reg-shift
was already being handled.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
arch/powerpc/boot/ns16550.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..da9d2c2 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ u32 reg_offset;
n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
+ n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
+ if (n == sizeof(reg_offset))
+ reg_base += reg_offset;
+
n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
--
1.5.2.1
^ permalink raw reply related
* Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-04-02 17:02 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cel, cbe-oss-dev, linux-kernel
In-Reply-To: <1207154567.7132.396.camel@carll-linux-desktop>
On Wed, 2008-04-02 at 09:42 -0700, Carl Love wrote:
> On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> > On Tuesday 25 March 2008, Carl Love wrote:
> > > This patch fixes a bug in the code that records the SPU data and
> > > context switches. The buffer_mutex lock must be held when the
> > > kernel is adding data to the buffer between the kernel and the
> > > OProfile daemon. The lock is not being held in the current code
> > > base. This patch fixes the bug using work queues. The data to
> > > be passed to the daemon is caputured by the interrupt handler.
> > > The workqueue function is invoked to grab the buffer_mutex lock
> > > and add the data to the buffer.
> >
> > So what was the exact bug you're fixing with this? There was no
> > buffer_mutex before, so why do you need it now? Can't this be a
> > spinlock so you can get it from interrupt context instead of
> > using a workqueue?
>
> The generic OProfile code defines a mutex lock, called buffer_mutex, to
> protect the kernel/daemon data buffer from being writen by the kernal
> and simultaneously read by the Daemon. When adding a PPU sample the
> oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is
> called from the interrupt context to request the sample be stored. The
> generic oprofile code takes care of passing the data to a non interrupt
> context where the mutex lock is held and the necessary sequence of data
> is written into the kernel/daemon data buffer. However, OProfile does
> not have any built in functions for handling the SPU. Hence, we have to
> implement the code to capture the data in the interrupt context, pass it
> to a non interrupt context and put it into the buffer. This was not
> done correctly in the original implementation. Specifically, the mutex
> lock was not being held.
>
> Writing data to the OProfile buffer consists of a sequence of items.
> For example when writing an SPU entry, first comes the escape code so
> the daemon knows this is a new entry. The next item is the SPU context
> switch code which says the data which will follow is the information
> about a new context. There is a different code to identify the data as
> an address sample. Finally the data about the SPU context switch is
> entered into the buffer. The issue is the OProfile daemon is read all
> of the entire sequence of items then process the data. Without the
> mutex lock, the daemon may read part of the sequence try to process it
> before everything is written into the buffer. When the daemon reads
> again, it doesn't see the escape code as the first item and isn't smart
> enough to realize it is part of a previous sequence. The generic
> OProfile code defines the mutex lock and calls it buffer_mutex. The
> OProfile kernel/daemon API uses the mutex lock. The mutex lock can only
> be held in a non interrupt context. The current implementation uses a
> spin lock to make sure the kernel writes each sequence if items into the
> buffer but since the API does not use a spin lock we have no way to
> prevent the daemon from reading the buffer until the entire sequence of
> items has been written to the buffer. Hence the need to hold the
> buffer_mutex lock which prevents the daemon from accessing the buffer.
>
> >
> > > Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > > ===================================================================
> > > --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> > > +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > > @@ -16,6 +16,7 @@
> > > #include <linux/smp.h>
> > > #include <linux/slab.h>
> > > #include <asm/cell-pmu.h>
> > > +#include <linux/workqueue.h>
> > > #include "pr_util.h"
> > >
> >
> > Please keep #include statements in alphabetical order, with all linux/ files
> > before the asm/ files.
> >
> > > #define TRACE_ARRAY_SIZE 1024
> > > @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
> > >
> > > #define SPU_PC_MASK 0xFFFF
> > >
> > > +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> > > + * between the kernel and the daemon. The SPU code needs to use the buffer
> > > + * to ensure that the kernel SPU writes complete as a single block before
> > > + * being consumed by the daemon.
> > > + */
> > > +extern struct mutex buffer_mutex;
> > > +
> > > static DEFINE_SPINLOCK(sample_array_lock);
> > > unsigned long sample_array_lock_flags;
> > >
> > > +struct work_struct spu_record_wq;
> > > +extern struct workqueue_struct *oprofile_spu_wq;
> > > +
> > > void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int cycles_reset)
> > > {
> > > unsigned long ns_per_cyc;
> >
> > Never put extern statements in the implementation, they describe the
> > interface between two parts of the code and should be inside of a
> > common header.
> >
> > Why do you want to have your own workqueue instead of using the
> > global one?
It is important that the data get context switch data get recorded as
quickly as possible to avoid dropping data unnecessarily. The PC
counter data for each SPU is ignored until the context switch record is
put into the kernel/daemon buffer. The API documentation says that
using a private workqueue has better performance then using the global
workqueue. There is a comment in the code about this, perhaps it is not
clear enough.
> >
> > > @@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
> > > return entry;
> > > }
> > >
> > > -
> > > -static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > > -{
> > > - ktime_t kt;
> > > +static void profile_spus_record_samples (struct work_struct *ws) {
> > > + /* This routine is called via schedule_work() to record the
> > > + * spu data. It must be run in a normal kernel mode to
> > > + * grab the OProfile mutex lock.
> > > + */
> > > int cpu, node, k, num_samples, spu_num;
> > >
> > > - if (!spu_prof_running)
> > > - goto stop;
> > > + mutex_lock(&buffer_mutex);
> > >
> > > for_each_online_cpu(cpu) {
> > > if (cbe_get_hw_thread_id(cpu))
> > > @@ -170,6 +181,20 @@ static enum hrtimer_restart profile_spus
> > > smp_wmb(); /* insure spu event buffer updates are written */
> > > /* don't want events intermingled... */
> > >
> > > + mutex_unlock(&buffer_mutex);
> > > +}
> > > +
> > > +static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > > +{
> > > + ktime_t kt;
> > > +
> > > +
> > > + if (!spu_prof_running)
> > > + goto stop;
> > > +
> > > + /* schedule the funtion to record the data */
> > > + schedule_work(&spu_record_wq);
> > > +
> > > kt = ktime_set(0, profiling_interval);
> > > if (!spu_prof_running)
> > > goto stop;
> >
> > This looks like you want to use a delayed_work rather than building your
> > own out of hrtimer and work. Is there any point why you want to use
> > an hrtimer?
>
> The current implementation uses the hrtimer to schedule when to read the
> trace buffer the next time. This patch does not change how the
> scheduling of the buffer reads is done. Yes, you could change the
> implementation to use workqueues instead. If you feel that it is better
> to use the workqueue then we could make that change. Not sure that
> making that change in this bug fix patch is appropriate. I would need
> to create a second patch for that change.
> >
> > > -static DEFINE_SPINLOCK(buffer_lock);
> > > +extern struct mutex buffer_mutex;
> > > +extern struct workqueue_struct *oprofile_spu_wq;
> > > +extern int calls_to_record_switch;
> > > +
> >
> > Again, public interfaces need to go to a header file, and should
> > have a name that identifies the interface. "buffer_mutex" is
> > certainly not a suitable name for a kernel-wide global variable!
>
> As stated earlier, the generic OProfile code defines the variable
> "buffer_mutex". Changing the name in the generic OProfile code is
> beyond the scope of this patch.
>
> >
> > > static DEFINE_SPINLOCK(cache_lock);
> > > static int num_spu_nodes;
> > > +
> > > int spu_prof_num_nodes;
> > > int last_guard_val[MAX_NUMNODES * 8];
> > > +int cnt_swtch_processed_flag[MAX_NUMNODES * 8];
> > > +
> > > +struct spus_profiling_code_data_s {
> > > + int num_spu_nodes;
> > > + struct work_struct spu_prof_code_wq;
> > > +} spus_profiling_code_data;
> > > +
> > > +struct spu_context_switch_data_s {
> > > + struct spu *spu;
> > > + unsigned long spu_cookie;
> > > + unsigned long app_dcookie;
> > > + unsigned int offset;
> > > + unsigned long objectId;
> > > + int valid_entry;
> > > +} spu_context_switch_data;
> >
> > I don't understand what these variables are really doing, but
> > having e.g. just one spu_context_switch_data for all the SPUs
> > doesn't seem to make much sense. What happens when two SPUs do
> > a context switch at the same time?
>
> This is the data same data that was being put into the event buffer
> directly from the interrupt context. We need to store the data that is
> only available in the interrupt context so the same data can be put into
> the buffer by the work queue function in the non interrupt context.
> This is the declaration of the data needed per SPU. Below in the
> spu_cntx_sw_data structure, we declare an array of entries so we can
> store the switch
oops, accidentally hit save when I tried to move the window. Sorry.
data on a per SPU basis as you alluded to.
> >
> > > +int calls_to_record_switch = 0;
> > > +int record_spu_start_flag = 0;
> > > +
> > > +struct spus_cntxt_sw_data_s {
> > > + int num_spu_nodes;
> > > + struct spu_context_switch_data_s spu_data[MAX_NUMNODES * 8];
> > > + struct work_struct spu_cntxt_work;
> > > +} spus_cntxt_sw_data;
> >
> > Something is very wrong if you need so many global variables!
The calls_to_record_switch variable is not used, my mistake for not
getting it out of the patch. The record_spu_stat_flag is used. It is
set in the spu_sync_start when SPU profiling is started. The first time
the work function is called to record SPU context switches it sees the
flag is set and writes the initial record to the daemon/kernel buffer
stating that this is an SPU profile run not a PPU profile run. The
daemon needs to know this as it effects how the postprocessing is done.
The initial record is only written once.
The spus_context_sw_data structure has the array per SPU for all off the
interrupt context data that was recorded and needs to be written to the
kernel/daemon buffer.
> >
> > > /* Container for caching information about an active SPU task. */
> > > struct cached_info {
> > > @@ -44,6 +73,8 @@ struct cached_info {
> > > struct kref cache_ref;
> > > };
> > >
> > > +struct workqueue_struct *oprofile_spu_wq;
> > > +
> > > static struct cached_info *spu_info[MAX_NUMNODES * 8];
> >
> > While you're cleaning this up, I guess the cached_info should
> > be moved into a pointer from struct spu as well, instead of
> > having this global variable here.
This would be a functional change and it belongs in a functional change
patch not in a bug fix patch.
> >
> > > @@ -375,16 +457,30 @@ int spu_sync_start(void)
> > > int k;
> > > int ret = SKIP_GENERIC_SYNC;
> > > int register_ret;
> > > - unsigned long flags = 0;
> > >
> > > spu_prof_num_nodes = number_of_online_nodes();
> > > num_spu_nodes = spu_prof_num_nodes * 8;
> > >
> > > - spin_lock_irqsave(&buffer_lock, flags);
> > > - add_event_entry(ESCAPE_CODE);
> > > - add_event_entry(SPU_PROFILING_CODE);
> > > - add_event_entry(num_spu_nodes);
> > > - spin_unlock_irqrestore(&buffer_lock, flags);
> > > + /* create private work queue, execution of work is time critical */
> > > + oprofile_spu_wq = create_workqueue("spu_oprofile");
> > > +
> > > + /* due to a race when the spu is already running stuff, need to
> > > + * set a flag to tell the spu context switch to record the start
> > > + * before recording the context switches.
> > > + */
> > > + record_spu_start_flag = 1;
> > > +
> > > + spus_profiling_code_data.num_spu_nodes = num_spu_nodes;
> > > +
> > > + /* setup work queue functiion for recording context switch info */
> > > + spus_cntxt_sw_data.num_spu_nodes = num_spu_nodes;
> > > + for (k = 0; k<(MAX_NUMNODES * 8); k++) {
> > > + spus_cntxt_sw_data.spu_data[k].valid_entry = 0;
> > > + cnt_swtch_processed_flag[k] = 0;
> > > + }
> > > +
> > > + INIT_WORK(&spus_cntxt_sw_data.spu_cntxt_work,
> > > + record_spu_process_switch);
> >
> > I would guess that you need one work struct per SPU instead of a global
> > one, if you want to pass the SPU pointer as an argument.
> >
> > Arnd <><
We only need one work struct because we have an array that contains the
data for each SPU that has done a context switch.
^ permalink raw reply
* Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
From: Segher Boessenkool @ 2008-04-02 17:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <0F53B076-0A94-4A2D-8D9A-ED507B53ABE6@kernel.crashing.org>
> Ideally we get set the phys address the PHDR, but I'm not sure how to
> get the linker to do that.
I think you want to look at "AT" in the ld manual.
Segher
^ permalink raw reply
* Re: [RESEND3 PATCH] [POWERPC] mpc5200: Amalgamated DTS fixes and updates
From: Segher Boessenkool @ 2008-04-02 17:08 UTC (permalink / raw)
To: Bartlomiej Sieka; +Cc: linuxppc-dev
In-Reply-To: <20080402142417.5557.90153.stgit@pollux.denx.de>
> + lpb {
> + model = "fsl,lpb";
> + compatible = "fsl,lpb";
Please use a more descriptive name, if you can still change the binding.
"localplus" or something like that.
Maybe it's time to start an International Obfuscated Device Tree
Contest,
to serve as a warning by example?
:-)
Segher
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Kamalesh Babulal @ 2008-04-02 17:09 UTC (permalink / raw)
To: michael
Cc: linuxppc-dev, Andrew Morton, Badari Pulavarty, linux-kernel,
Balbir Singh
In-Reply-To: <1207120676.7349.11.camel@concordia.ozlabs.ibm.com>
Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>>>>
>>>> [ 0.000000] ------------[ cut here ]------------
>>>> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
>>>> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
>>>> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
>>>> [ 0.000000] Modules linked in:
>>>> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
>>>> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
>>>> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
>>>> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
>>>> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
>>>> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
>>>> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
>>>> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
>>>> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
>>>> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
>>>> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
>>>> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
>>>> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
>>>> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
>>>> [ 0.000000] Call Trace:
>>>> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
>>>> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
>>>> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
>>>> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
>>>> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
>>>> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
>>>> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
>>>> [ 0.000000] Instruction dump:
>>>> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
>>>> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
>>>> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
>>>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>>>>
>>> int __meminit vmemmap_populate(struct page *start_page,
>>> unsigned long nr_pages, int node)
>>> {
>>> unsigned long mode_rw;
>>> unsigned long start = (unsigned long)start_page;
>>> unsigned long end = (unsigned long)(start_page + nr_pages);
>>> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
>>>
>>> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>>>
>>> /* Align to the page size of the linear mapping. */
>>> start = _ALIGN_DOWN(start, page_size);
>>>
>>> for (; start < end; start += page_size) {
>>> int mapped;
>>> void *p;
>>>
>>> if (vmemmap_populated(start, page_size))
>>> continue;
>>>
>>> p = vmemmap_alloc_block(page_size, node);
>>> if (!p)
>>> return -ENOMEM;
>>>
>>> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
>>> start, p, __pa(p));
>>>
>>> mapped = htab_bolt_mapping(start, start + page_size,
>>> __pa(p), mode_rw, mmu_linear_psize,
>>> mmu_kernel_ssize);
>>> =====> BUG_ON(mapped < 0);
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> Beats me. pseries? Badari has been diddling with the bolted memory code
>>> in git-powerpc...
>> One of the machines is the Power5 and another is PowerMac G5, on which the
>> same kernel panic is seen.
>
> Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> should show what's happening in hpte_insert().
>
> cheers
>
Just define DEBUG_LOW did not fetch and debug information, so added some printk to
htab_bolt_mapping () and pSeries_lpar_hpte_insert ()
[boot]0012 Setup Arch
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 3000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000003000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 4000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000004000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 5000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000005000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 6000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000006000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 8000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000008000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 9000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000009000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart a000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000a000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart b000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000b000000, rflags=194, vflags=10, psize=4 ssize=0)
htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart c000000,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c000000000888f00
_hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000c000000, rflags=194, vflags=10, psize=4 ssize=0)
------------[ cut here ]------------
kernel BUG at arch/powerpc/mm/init_64.c:240!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c000000000774b88 LR: c000000000774b80 CTR: 0000000000000000
REGS: c0000000008f7950 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autotest)
MSR: 8000000000021032 <ME,IR,DR> CR: 24000088 XER: 00000001
TASK = c0000000007dffd0[0] 'swapper' THREAD: c0000000008f4000 CPU: 0
GPR00: c000000000774b80 c0000000008f7bd0 c0000000008f6c00 0000000000000001
GPR04: fffffffffffffffa 000000000000005f 000000000000005e 0000000000000477
GPR08: 00000009b346bb78 8000000006520800 fffffffffffffffa ffffffffffffffff
GPR12: 0000000024000082 c0000000007e0980 0000000000000000 c00000000069ab58
GPR16: 4000000001c00000 c0000000006993e8 0000000000000000 00000000002b1000
GPR20: 000000000237b450 c00000000077b450 000000000237b6c0 c00000000077b6c0
GPR24: c00000000069a5a0 0000000002700000 c0000000009b0000 0000000000000000
GPR28: cf000000001f8000 cf00000001000000 0000000001000000 cf00000000000000
NIP [c000000000774b88] .vmemmap_populate+0xbc/0x100
LR [c000000000774b80] .vmemmap_populate+0xb4/0x100
Call Trace:
[c0000000008f7bd0] [c000000000774b80] .vmemmap_populate+0xb4/0x100 (unreliable)
[c0000000008f7c70] [c0000000007757e4] .sparse_mem_map_populate+0x38/0x5c
[c0000000008f7d00] [c000000000762f14] .sparse_early_mem_map_alloc+0x54/0x94
[c0000000008f7d90] [c000000000763348] .sparse_init+0x1e8/0x224
[c0000000008f7e50] [c00000000074f428] .setup_arch+0x1ac/0x218
[c0000000008f7ee0] [c0000000007466bc] .start_kernel+0xe0/0x414
[c0000000008f7f90] [c000000000008594] .start_here_common+0x54/0xc0
Instruction dump:
7fe3fb78 7ca02a14 4082000c 3860fff4 48000040 e9228980 e9628988 e8e90002
e90b0002 4b8b712d 60000000 78630fe0 <0b030000> 7ffff214 7fbdf214 7fbfe040
---[ end trace 31fd0ba7d8756001 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Badari Pulavarty @ 2008-04-02 18:15 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, Andrew Morton, lkml, Balbir Singh
In-Reply-To: <47F3BDD4.1010905@linux.vnet.ibm.com>
On Wed, 2008-04-02 at 22:39 +0530, Kamalesh Babulal wrote:
> Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> >> Andrew Morton wrote:
> >>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> >>>
> >>>> Hi Andrew,
> >>>>
> >>>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >>>>
> >>>> [ 0.000000] ------------[ cut here ]------------
> >>>> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> >>>> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> >>>> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> >>>> [ 0.000000] Modules linked in:
> >>>> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> >>>> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> >>>> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> >>>> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> >>>> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> >>>> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> >>>> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> >>>> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> >>>> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> >>>> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> >>>> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> >>>> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> >>>> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> >>>> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> >>>> [ 0.000000] Call Trace:
> >>>> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> >>>> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> >>>> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> >>>> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> >>>> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> >>>> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> >>>> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> >>>> [ 0.000000] Instruction dump:
> >>>> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> >>>> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> >>>> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> >>>> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> >>>>
> >>> int __meminit vmemmap_populate(struct page *start_page,
> >>> unsigned long nr_pages, int node)
> >>> {
> >>> unsigned long mode_rw;
> >>> unsigned long start = (unsigned long)start_page;
> >>> unsigned long end = (unsigned long)(start_page + nr_pages);
> >>> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> >>>
> >>> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> >>>
> >>> /* Align to the page size of the linear mapping. */
> >>> start = _ALIGN_DOWN(start, page_size);
> >>>
> >>> for (; start < end; start += page_size) {
> >>> int mapped;
> >>> void *p;
> >>>
> >>> if (vmemmap_populated(start, page_size))
> >>> continue;
> >>>
> >>> p = vmemmap_alloc_block(page_size, node);
> >>> if (!p)
> >>> return -ENOMEM;
> >>>
> >>> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> >>> start, p, __pa(p));
> >>>
> >>> mapped = htab_bolt_mapping(start, start + page_size,
> >>> __pa(p), mode_rw, mmu_linear_psize,
> >>> mmu_kernel_ssize);
> >>> =====> BUG_ON(mapped < 0);
> >>> }
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> Beats me. pseries? Badari has been diddling with the bolted memory code
> >>> in git-powerpc...
> >> One of the machines is the Power5 and another is PowerMac G5, on which the
> >> same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> > should show what's happening in hpte_insert().
> >
> > cheers
> >
> Just define DEBUG_LOW did not fetch and debug information, so added some printk to
> htab_bolt_mapping () and pSeries_lpar_hpte_insert ()
>
> [boot]0012 Setup Arch
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 3000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000003000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 4000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000004000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 5000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000005000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 6000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000006000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 8000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000008000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart 9000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=0000000009000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart a000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000a000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart b000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000b000000, rflags=194, vflags=10, psize=4 ssize=0)
> htab_bolt_mapping (vstart cf00000000000000, vend cf00000001000000, pstart c000000,mode 190, psize 4, ssize 0)
> htab_bolt_mapping: calling c000000000888f00
> _hpte_insert(group=252078, va=d59aca40f0000000, pa=000000000c000000, rflags=194, vflags=10, psize=4 ssize=0)
>
> ------------[ cut here ]------------
> kernel BUG at arch/powerpc/mm/init_64.c:240!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=128 NUMA pSeries
> Modules linked in:
> NIP: c000000000774b88 LR: c000000000774b80 CTR: 0000000000000000
> REGS: c0000000008f7950 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autotest)
> MSR: 8000000000021032 <ME,IR,DR> CR: 24000088 XER: 00000001
> TASK = c0000000007dffd0[0] 'swapper' THREAD: c0000000008f4000 CPU: 0
>
> GPR00: c000000000774b80 c0000000008f7bd0 c0000000008f6c00 0000000000000001
> GPR04: fffffffffffffffa 000000000000005f 000000000000005e 0000000000000477
> GPR08: 00000009b346bb78 8000000006520800 fffffffffffffffa ffffffffffffffff
> GPR12: 0000000024000082 c0000000007e0980 0000000000000000 c00000000069ab58
> GPR16: 4000000001c00000 c0000000006993e8 0000000000000000 00000000002b1000
> GPR20: 000000000237b450 c00000000077b450 000000000237b6c0 c00000000077b6c0
> GPR24: c00000000069a5a0 0000000002700000 c0000000009b0000 0000000000000000
> GPR28: cf000000001f8000 cf00000001000000 0000000001000000 cf00000000000000
>
> NIP [c000000000774b88] .vmemmap_populate+0xbc/0x100
> LR [c000000000774b80] .vmemmap_populate+0xb4/0x100
>
> Call Trace:
> [c0000000008f7bd0] [c000000000774b80] .vmemmap_populate+0xb4/0x100 (unreliable)
> [c0000000008f7c70] [c0000000007757e4] .sparse_mem_map_populate+0x38/0x5c
> [c0000000008f7d00] [c000000000762f14] .sparse_early_mem_map_alloc+0x54/0x94
> [c0000000008f7d90] [c000000000763348] .sparse_init+0x1e8/0x224
> [c0000000008f7e50] [c00000000074f428] .setup_arch+0x1ac/0x218
> [c0000000008f7ee0] [c0000000007466bc] .start_kernel+0xe0/0x414
> [c0000000008f7f90] [c000000000008594] .start_here_common+0x54/0xc0
>
> Instruction dump:
> 7fe3fb78 7ca02a14 4082000c 3860fff4 48000040 e9228980 e9628988 e8e90002
> e90b0002 4b8b712d 60000000 78630fe0 <0b030000> 7ffff214 7fbdf214 7fbfe040
> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
>
Kamalesh,
With your config, I am able to reproduce the problem. I haven't touched
that part of code. I can take a look at it. It looks like we are trying
to create mapping for same "vaddr" multiple times and we get failures
after few creates. I am not sure why we are trying to create so many
times with same vaddr.
Thanks,
Badari
^ permalink raw reply
* u-boot ppc440epx bootstrap configuration without eval board
From: Dave Cogley @ 2008-04-02 17:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
Hello,
We are using the new AMCC ppc440epx 667MHz chip and I am trying to get
u-boot to recognize the clock rate of the new chip (we were using the
533MHz). I notice in the cmd_sequoia.c module that there is an option to
setup some sort of strapping in the configuration FPGA that was present on
the evaluation card. We do not have this configuration FPGA present in our
production board. Is there some sort of build flag I can specify to
"hardwire" this bootstrap information? Or at least some I can tell u-boot
to startup with the 667MHz clock rate? I believe we are using option 7 in
the configuration array for the "bootstrap" command.
Thanks,
Dave Cogley
Software Engineer
Ultra Stereo Labs, Inc.
(805) 549-0161
mailto:dcogley@uslinc.com
[-- Attachment #2: Type: text/html, Size: 3297 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Grant Likely @ 2008-04-02 17:46 UTC (permalink / raw)
To: John Linn, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20080402165216.8FD2BC9807F@mail21-dub.bigfish.com>
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> From: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
>
> The of_serial driver queries the current-speed property and attempts
> to use it to register the custom_divisor property of the uart_port.
> However, if current-speed is not set, then this code will dereference
> a bad pointer. The fix is to only set custom_divisor when a
> current-speed property appears in the device tree.
>
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Paul, can you please pick this one up for .25? It is pure bug fix.
Thanks,
g.
> ---
> drivers/serial/of_serial.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index a64d858..2efb892 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT;
> port->dev = &ofdev->dev;
> - port->custom_divisor = *clk / (16 * (*spd));
> + /* If current-speed was set, then try not to change it. */
> + if (spd)
> + port->custom_divisor = *clk / (16 * (*spd));
>
> return 0;
> }
> --
> 1.5.2.1
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-02 17:52 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165216.C835D1CF8088@mail12-sin.bigfish.com>
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the ns16550 driver to use the reg-offset property
> so that the Xilinx UART 16550 can be used with it. The reg-shift
> was already being handled.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> arch/powerpc/boot/ns16550.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> index f8f1b2f..da9d2c2 100644
> --- a/arch/powerpc/boot/ns16550.c
> +++ b/arch/powerpc/boot/ns16550.c
> @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> {
> int n;
> unsigned long reg_phys;
> + u32 reg_offset;
>
> n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> if (n != sizeof(reg_base)) {
> @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct serial_console_data *scdp)
> reg_base = (void *)reg_phys;
> }
>
> + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> + if (n == sizeof(reg_offset))
> + reg_base += reg_offset;
> +
> n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
> if (n != sizeof(reg_shift))
> reg_shift = 0;
> --
> 1.5.2.1
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: Grant Likely @ 2008-04-02 18:00 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080402165222.2468414080A9@mail104-dub.bigfish.com>
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Comments below...
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++++++++++
> drivers/serial/of_serial.c | 15 +++++++++++++--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such that they
> + use the ns16550 binding with properties to specify register spacing and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..af9ed48 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->node;
> - const unsigned int *clk, *spd;
> + const unsigned int *clk, *spd, *reg_offset, *reg_shift;
These should really be u32's I believe; on 64 bit architectures this
will misbehave (not an immediate practical problem, but it's best to
be explicit about these things).
> int ret;
>
> memset(port, 0, sizeof *port);
> @@ -48,7 +48,18 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> }
>
> spin_lock_init(&port->lock);
> - port->mapbase = resource.start;
> +
> + reg_offset = of_get_property(np, "reg-offset", NULL);
> + reg_shift = of_get_property(np, "reg-shift", NULL);
> +
> + if (!reg_offset)
> + port->mapbase = resource.start;
> + else
> + port->mapbase = resource.start + *reg_offset;
> +
> + if (reg_shift)
> + port->regshift = *reg_shift;
> +
This is a little unsafe since it doesn't check the property size, I'd
do the following instead:
port->mapbase = resource.start
/* Check for shifted address mapping */
prop = of_get_property(np, "reg-offset", &prop_size);
if (prop && (prop_size == sizeof(u32))
port->mapbase += *prop;
/* Check for registers offset within the devices address range */
prop = of_get_property(np, "reg-shift", &prop_size);
if (prop && (prop_size == sizeof(u32)))
port->regshift = *prop;
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: u-boot ppc440epx bootstrap configuration without eval board
From: Dave Cogley @ 2008-04-02 18:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]
Disregard the boot strapping problem. It appears we are hardwired strapped
to use option "C" however my CPU is not being recognized as a 667MHz. Which
option should I be using for the 667MHz processor?
_____
From: Dave Cogley [mailto:dcogley@uslinc.com]
Sent: Wednesday, April 02, 2008 10:15 AM
To: 'linuxppc-embedded@ozlabs.org'
Subject: u-boot ppc440epx bootstrap configuration without eval board
Hello,
We are using the new AMCC ppc440epx 667MHz chip and I am trying to get
u-boot to recognize the clock rate of the new chip (we were using the
533MHz). I notice in the cmd_sequoia.c module that there is an option to
setup some sort of strapping in the configuration FPGA that was present on
the evaluation card. We do not have this configuration FPGA present in our
production board. Is there some sort of build flag I can specify to
"hardwire" this bootstrap information? Or at least some I can tell u-boot
to startup with the 667MHz clock rate? I believe we are using option 7 in
the configuration array for the "bootstrap" command.
Thanks,
Dave Cogley
Software Engineer
Ultra Stereo Labs, Inc.
(805) 549-0161
mailto:dcogley@uslinc.com
[-- Attachment #2: Type: text/html, Size: 5247 bytes --]
^ permalink raw reply
* RE: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
From: John Linn @ 2008-04-02 18:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40804021100j13a7e223jde9d222df379b1f8@mail.gmail.com>
Sounds good, those are easy changes and make sense.
Since I'm a newbie, I don't know any better sometimes when I copy other
code that may not be as safe. =20
The same thing, of_get_property(np, "current-speed", NULL);, is done
right above my code I added. =20
Should the other code in the driver using the same method be fixed, or
just my patch?
Thanks for your patience,
John
-----Original Message-----
From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
Grant Likely
Sent: Wednesday, April 02, 2008 12:00 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for
Xilinx uart 16550.
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <john.linn@xilinx.com> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Comments below...
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++++++++++
> drivers/serial/of_serial.c | 15 +++++++++++++--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the
flattened-device-tree model.
> differ between different families. May be
> 'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such
that they
> + use the ns16550 binding with properties to specify register
spacing and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..af9ed48 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -30,7 +30,7 @@ static int __devinit
of_platform_serial_setup(struct of_device *ofdev,
> {
> struct resource resource;
> struct device_node *np =3D ofdev->node;
> - const unsigned int *clk, *spd;
> + const unsigned int *clk, *spd, *reg_offset, *reg_shift;
These should really be u32's I believe; on 64 bit architectures this
will misbehave (not an immediate practical problem, but it's best to
be explicit about these things).
> int ret;
>
> memset(port, 0, sizeof *port);
> @@ -48,7 +48,18 @@ static int __devinit
of_platform_serial_setup(struct of_device *ofdev,
> }
>
> spin_lock_init(&port->lock);
> - port->mapbase =3D resource.start;
> +
> + reg_offset =3D of_get_property(np, "reg-offset", NULL);
> + reg_shift =3D of_get_property(np, "reg-shift", NULL);
> +
> + if (!reg_offset)
> + port->mapbase =3D resource.start;
> + else
> + port->mapbase =3D resource.start + *reg_offset;
> +
> + if (reg_shift)
> + port->regshift =3D *reg_shift;
> +
This is a little unsafe since it doesn't check the property size, I'd
do the following instead:
port->mapbase =3D resource.start
/* Check for shifted address mapping */
prop =3D of_get_property(np, "reg-offset", &prop_size);
if (prop && (prop_size =3D=3D sizeof(u32))
port->mapbase +=3D *prop;
/* Check for registers offset within the devices address range */
prop =3D of_get_property(np, "reg-shift", &prop_size);
if (prop && (prop_size =3D=3D sizeof(u32)))
port->regshift =3D *prop;
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
From: Badari Pulavarty @ 2008-04-02 19:22 UTC (permalink / raw)
To: michael, yhlu.kernel
Cc: linuxppc-dev, Andrew Morton, Balbir Singh, lkml, Kamalesh Babulal
In-Reply-To: <1207120676.7349.11.camel@concordia.ozlabs.ibm.com>
On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > Andrew Morton wrote:
> > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> > >
> > >> Hi Andrew,
> > >>
> > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > >>
> > >> [ 0.000000] ------------[ cut here ]------------
> > >> [ 0.000000] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > >> [ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
> > >> [ 0.000000] SMP NR_CPUS=32 NUMA PowerMac
> > >> [ 0.000000] Modules linked in:
> > >> [ 0.000000] NIP: c0000000003d1dcc LR: c0000000003d1dc4 CTR: c00000000002b6ac
> > >> [ 0.000000] REGS: c00000000049b960 TRAP: 0700 Not tainted (2.6.25-rc8-mm1-autokern1)
> > >> [ 0.000000] MSR: 9000000000021032 <ME,IR,DR> CR: 44000088 XER: 20000000
> > >> [ 0.000000] TASK = c0000000003f9c90[0] 'swapper' THREAD: c000000000498000 CPU: 0
> > >> [ 0.000000] GPR00: c0000000003d1dc4 c00000000049bbe0 c0000000004989d0 0000000000000001
> > >> [ 0.000000] GPR04: d59aca40f0000000 000000000b000000 0000000000000010 0000000000000000
> > >> [ 0.000000] GPR08: 0000000000000004 0000000000000001 c00000027e520800 c0000000004bf0f0
> > >> [ 0.000000] GPR12: c0000000004bf020 c0000000003fa900 0000000000000000 0000000000000000
> > >> [ 0.000000] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > >> [ 0.000000] GPR20: 0000000000000000 0000000000000000 0000000000000000 4000000001400000
> > >> [ 0.000000] GPR24: 00000000017d64b0 c0000000003d6250 0000000000000000 c000000000504000
> > >> [ 0.000000] GPR28: 0000000000000000 cf000000001f8000 0000000001000000 cf00000000000000
> > >> [ 0.000000] NIP [c0000000003d1dcc] .vmemmap_populate+0xb8/0xf4
> > >> [ 0.000000] LR [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4
> > >> [ 0.000000] Call Trace:
> > >> [ 0.000000] [c00000000049bbe0] [c0000000003d1dc4] .vmemmap_populate+0xb0/0xf4 (unreliable)
> > >> [ 0.000000] [c00000000049bc70] [c0000000003d2ee8] .sparse_mem_map_populate+0x38/0x60
> > >> [ 0.000000] [c00000000049bd00] [c0000000003c242c] .sparse_early_mem_map_alloc+0x54/0x94
> > >> [ 0.000000] [c00000000049bd90] [c0000000003c250c] .sparse_init+0xa0/0x20c
> > >> [ 0.000000] [c00000000049be50] [c0000000003ab7d0] .setup_arch+0x1ac/0x218
> > >> [ 0.000000] [c00000000049bee0] [c0000000003a36ac] .start_kernel+0xe0/0x3fc
> > >> [ 0.000000] [c00000000049bf90] [c000000000008594] .start_here_common+0x54/0xc0
> > >> [ 0.000000] Instruction dump:
> > >> [ 0.000000] 7fe3fb78 7ca02a14 4082000c 3860fff4 4800003c e92289c8 e96289c0 e9090002
> > >> [ 0.000000] e8eb0002 4bc575cd 60000000 78630fe0 <0b030000> 7ffff214 7fbfe840 7fe3fb78
> > >> [ 0.000000] ---[ end trace 31fd0ba7d8756001 ]---
> > >> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
> > >>
> > >
> > > int __meminit vmemmap_populate(struct page *start_page,
> > > unsigned long nr_pages, int node)
> > > {
> > > unsigned long mode_rw;
> > > unsigned long start = (unsigned long)start_page;
> > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> > >
> > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > >
> > > /* Align to the page size of the linear mapping. */
> > > start = _ALIGN_DOWN(start, page_size);
> > >
> > > for (; start < end; start += page_size) {
> > > int mapped;
> > > void *p;
> > >
> > > if (vmemmap_populated(start, page_size))
> > > continue;
> > >
> > > p = vmemmap_alloc_block(page_size, node);
> > > if (!p)
> > > return -ENOMEM;
> > >
> > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > start, p, __pa(p));
> > >
> > > mapped = htab_bolt_mapping(start, start + page_size,
> > > __pa(p), mode_rw, mmu_linear_psize,
> > > mmu_kernel_ssize);
> > > =====> BUG_ON(mapped < 0);
> > > }
> > >
> > > return 0;
> > > }
> > >
> > > Beats me. pseries? Badari has been diddling with the bolted memory code
> > > in git-powerpc...
> >
> > One of the machines is the Power5 and another is PowerMac G5, on which the
> > same kernel panic is seen.
>
> Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> should show what's happening in hpte_insert().
>
> cheers
>
Okay. Found it.
Root cause is:
mm-make-mem_map-allocation-continuous.patch
and its friends in -mm.
You have to call sparse_init_one_section() on each pmap and usemap
as we allocate - since valid_section() depends on it (which is needed
by vmemmap_populate() to check if the section is populated or not).
On ppc, we need to call htab_bolted_mapping() on each section and
we need to skip existing sections.
These patches tried to group all allocations together and then later
calls sparse_init_one_section() - which is not good :(
Please let me know, if its doesn't make sense - I will try to explain
better :)
Thanks,
Badari
^ permalink raw reply
* ppc405ep and Ready enable in EBC0_BnAP register
From: ravi.rao @ 2008-04-02 18:35 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
Hi All,
Our target is based on PPC405EP and we are using a TDMoIP chip on the
peripheral bus with chipselect 2. Since the access time to the chip is not
deterministic we are planning to use the Ready enable. By probing into
Chipselect and ready enable bits it looks like the chip select gets
extended untill the ready enable becomes 1 but the access crashes with a
Bus error.
But If I just set the twt to a very high value say 20 with ready enable
set to 0 then it works. Any pointers to understand what is happening
will be of great help.
####################### Screen Dump #################################
Data machine check in kernel mode.
PLB0: BEAR= 0xf8000000 ACR= 0x00000000 BESR= 0x00000000
PLB0 to OPB: BEAR= 0x01000000 BESR0= 0x00000000 BESR1= 0x00000000
Oops: machine check, sig: 7 [#5]
NIP: C90C69BC LR: C90C6AA4 CTR: 000003E0
REGS: c023ef50 TRAP: 0202 Not tainted (2.6.21)
MSR: 00029030 <EE,ME,IR,DR> CR: 84044408 XER: 00000007
TASK = c3fab050[666] 'cat' THREAD: c2710000
GPR00: 00000000 C2711650 C3FAB050 C2729000 C2711EAC 00000000 00000C00
C2711EA8
GPR08: 00000000 00000040 FFFFFFFF C9400000 44044408 100A54C0 03FF9C00
00000001
GPR16: 0000005E C01DA824 C02E7F78 C01E0C50 C2711EA8 C01E0C20 C2711EAC
C25DC320
GPR24: C2729000 00000000 C2711F20 C90C7FF4 C2729000 C2711EA8 C2711658
C2729000
Call Trace:
[C2711E80] [C90C6AA4]
[C2711EA0] [C009BA60]
[C2711EF0] [C0063E6C]
[C2711F10] [C00642C8]
[C2711F40] [C0002CB4]
Instruction dump:
bf210814 3b697ff4 90010834 817b006c 7c7f1b78 a00b0000 39200002 b0010008
380003ff 7c0903a6 3bc10008 7c0b4a2e <7c09f32e> 39290002 4200fff4 3c80c90c
Bus error
Thanks,
Ravishankar Govindarao
RFL Electronics Inc.
E-mail : Ravi.Rao@rflelect.com
Voice: 973.334.3100 Ext. 233
Fax: 973.334.3863
CONFIDENTIALITY NOTE
This e-mail, including any attachments, may contain confidential and/or
legally privileged information. The Information is intended only for the
use of the individual or entity named on this e-mail . If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the contents of
this transmitted Information is strictly prohibited. Further, if you are
not the intended recipient, please notify us by return e-mail and delete
the Information promptly.
[-- Attachment #2: Type: text/html, Size: 4149 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox