* Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
From: Roland Dreier @ 2008-08-20 17:19 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd, Bergmann
In-Reply-To: <20080820131124.05cfee9f@zod.rchland.ibm.com>
> Except that logically doesn't make much sense. Why would you have a
> list of mpc52xx and 44x boards together? They require completely
> different kernels because the MMU and drive set is entirely different.
>
> Or am I totally missing what you are saying?
Yeah, I wasn't clear -- I meant to add a new helper like
of_flat_dt_is_compatible_list() (not sure of the name) that takes a node
and a NULL-terminated array of strings, and then mpc5200_simple_probe()
can become a one-liner, along with mpc5121_generic_probe(),
tqm85xx_probe(), ppc44x_probe(), etc.
- R.
^ permalink raw reply
* Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
From: Josh Boyer @ 2008-08-20 17:35 UTC (permalink / raw)
To: Roland Dreier; +Cc: linuxppc-dev, Arnd, Bergmann
In-Reply-To: <ada7iabpptl.fsf@cisco.com>
On Wed, 20 Aug 2008 10:19:02 -0700
Roland Dreier <rdreier@cisco.com> wrote:
> > Except that logically doesn't make much sense. Why would you have a
> > list of mpc52xx and 44x boards together? They require completely
> > different kernels because the MMU and drive set is entirely different.
> >
> > Or am I totally missing what you are saying?
>
> Yeah, I wasn't clear -- I meant to add a new helper like
> of_flat_dt_is_compatible_list() (not sure of the name) that takes a node
> and a NULL-terminated array of strings, and then mpc5200_simple_probe()
> can become a one-liner, along with mpc5121_generic_probe(),
> tqm85xx_probe(), ppc44x_probe(), etc.
Ah, I see.
I worry about doing that though. I don't want to give people the
impression that these boards are "of" compatible. I want it to be more
"this file supports these explicit platforms and makes no claim on
compatibility between them".
josh
^ permalink raw reply
* Re: cache model of ppc
From: Josh Boyer @ 2008-08-20 17:36 UTC (permalink / raw)
To: Felix Schmidt; +Cc: linuxppc-dev
In-Reply-To: <48AC388D.1090609@web.de>
On Wed, 2008-08-20 at 17:30 +0200, Felix Schmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear,
>
> I some questions about the PowerPC cache model.
It depends greatly on the core, chip, and cache used. That varies
widely across the PPC universe.
josh
^ permalink raw reply
* RE: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 EthernetNIC
From: John Linn @ 2008-08-20 17:39 UTC (permalink / raw)
To: dhlii, linuxppc-embedded, netdev; +Cc: Ben Hutchings, Stephen Neuendorffer
In-Reply-To: <48AA938C.4060309@dlasys.net>
I'm not claiming to be a Linux driver expert as I'm still learning.
Some of the comments are nits.
Thanks for the effort you're putting in on this.
> Linux Device Driver for Xilinx LL TEMAC 10/100/1000 Ethernet NIC
> =
> Original Author Yoshio Kashiwagi
> Updated and Maintained by David Lynch
> =
> Signed-off-by: David H. Lynch Jr. <dhlii@dlasys.net>
> =
> ---
> =
> drivers/net/Kconfig | 5 =
> drivers/net/Makefile | 1 =
> drivers/net/xps_lltemac.c | 1562
++++++++++++++++++++++++++++++++++++++++
> include/linux/xilinx_devices.h | 2 =
> 4 files changed, 1569 insertions(+), 1 deletions(-)
> =
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 033e13f..71b4c17 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2332,6 +2332,11 @@ config MV643XX_ETH
> Some boards that use the Discovery chipset are the Momenco
> Ocelot C and Jaguar ATX and Pegasos II.
> =
> +config XPS_LLTEMAC
> + tristate "Xilinx LLTEMAC 10/100/1000 Ethernet MAC driver"
> + help
> + This driver supports the Xilinx 10/100/1000 LLTEMAC found in
Virtex 4 FPGAs
It might be helpful to say only in DMA mode as our traditional drivers
support FIFO mode and DMA. =
Since the FPGA is pretty flexible people tend to do things different
than I sometimes expect.
> +
> config QLA3XXX
> tristate "QLogic QLA3XXX Network Driver Support"
> depends on PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 1f09934..9196bab 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -126,6 +126,7 @@ obj-$(CONFIG_AX88796) +=3D ax88796.o
> obj-$(CONFIG_TSI108_ETH) +=3D tsi108_eth.o
> obj-$(CONFIG_PICO_TEMAC) +=3D pico_temac.o
> obj-$(CONFIG_MV643XX_ETH) +=3D mv643xx_eth.o
> +obj-$(CONFIG_XPS_LLTEMAC) +=3D xps_lltemac.o
> obj-$(CONFIG_QLA3XXX) +=3D qla3xxx.o
> =
> obj-$(CONFIG_PPP) +=3D ppp_generic.o
> diff --git a/drivers/net/xps_lltemac.c b/drivers/net/xps_lltemac.c
> new file mode 100644
> index 0000000..8af4e7a
> --- /dev/null
> +++ b/drivers/net/xps_lltemac.c
> @@ -0,0 +1,1562 @@
>
+/*=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D
> +
> + Driver for Xilinx temac ethernet NIC's
Saying LL TEMAC would be clearer as we having older TEMACs that are yet
different and not local link (LL).
It's definitely not a NIC in the traditional sense of a PCI card, but is
an SOC core.
> +
> + Author: Yoshio Kashiwagi
> + Copyright (c) 2008 Nissin Systems Co.,Ltd.
> +
> + Revisons: David H. Lynch Jr. <dhlii@dlasys.net>
> + Copyright (C) 2005-2008 DLA Systems
> +
>
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D*
/
> +/* DRV_NAME is for compatibility with existing xilinx ll temac driver
> + * also with of/dtc object names */
> +#define DRV_NAME "xilinx_lltemac"
> +#define DRV_AUTHOR "Yoshio Kashiwagi"
> +#define DRV_EMAIL ""
> +
> +#include <linux/module.h>
> +#include <linux/netdevice.h>
> +#include <linux/etherdevice.h>
> +#include <linux/init.h>
> +#include <linux/skbuff.h>
> +#include <linux/platform_device.h>
> +#include <linux/spinlock.h>
> +
> +#include <linux/mii.h>
> +#include <linux/in.h>
> +#include <linux/pci.h>
> +
> +#include <linux/ip.h>
> +#include <linux/tcp.h> /* just needed for sizeof(tcphdr) */
> +#include <linux/udp.h> /* needed for sizeof(udphdr) */
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +
> +#define MII_ANI 0x10
> +#define PHY_NUM 0
This phy number, (phy address), won't work for a number of Xilinx
boards. It seems like this should be either pulled from the platform
data (and device tree), or the driver should try to find the PHY address
by trying each one.
Otherwise the users will have to edit the driver all the time when their
phy is not address 0.
> +#define PHY_TIMEOUT 10000
> +
<snip>
> +static unsigned int
> +mdio_read(struct net_device *ndev, int phy_id, int reg_num)
> +{
> + struct temac_local *lp =3D netdev_priv(ndev);
> + u32 timeout =3D PHY_TIMEOUT;
> + u32 rv =3D 0;
> + unsigned long flags;
> +
> + if ((reg_num > MII_REG_MAX) ||
> + (phy_id =3D=3D PHY_ADDR_INVALID)) {
The phy_id never gets set to PHY_ADDR_INVALID, is there something I'm
missing or should this be removed? Maybe this is related to the PHY_NUM
hard coded value that could be set invalid.
> + dev_err(&ndev->dev,
> + "mdio_read(%x, %x) invalid reg_num or invalid
phy_id\n",
> + reg_num, phy_id);
> + return -1;
Returning a negative value for failure makes sense, but not when the
return type is unsigned int, should it be an int instead?
I put in nits about return types and I realize their nits, but should
make the driver better was my
hope.
> + }
> +
> + spin_lock_irqsave(&lp->lock, flags);
> +
> + tiow(ndev, XTE_LSW0_OFFSET,
> + ((phy_id << 5) | (reg_num)));
> + tiow(ndev, XTE_CTL0_OFFSET,
> + XTE_MIIMAI_OFFSET | (lp->emac_num << 10));
> + while (!(tior(ndev, XTE_RDY0_OFFSET) & XTE_RSE_MIIM_RR_MASK)) {
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev, "read_MII busy
timeout!!\n");
> + return -1;
> + }
> + }
> + rv =3D tior(ndev, XTE_LSW0_OFFSET);
> +
> + spin_unlock_irqrestore(&lp->lock, flags);
> + return rv;
> +}
> +
> +static void
> +mdio_write(struct net_device *ndev, int phy_id, int reg_num, int
reg_val)
> +{
> + struct temac_local *lp =3D netdev_priv(ndev);
> + u32 timeout =3D PHY_TIMEOUT, status;
> + unsigned long flags;
> +
> + if ((reg_num > MII_REG_MAX) ||
> + (phy_id =3D=3D PHY_ADDR_INVALID)) {
> + dev_err(&ndev->dev,
> + "mdio_write(%x, %x)invalid reg_num or invalid
phy_id\n",
> + reg_num, phy_id);
> + return -1;
The return type is void yet it tries to return -1, should it be int
return? =
> + }
> +
> + spin_lock_irqsave(&lp->lock, flags);
> +
> + tiow(ndev, XTE_LSW0_OFFSET,
> + reg_val);
> + tiow(ndev, XTE_CTL0_OFFSET,
> + CNTLREG_WRITE_ENABLE_MASK | XTE_MGTDR_OFFSET);
> + tiow(ndev, XTE_LSW0_OFFSET,
> + ((phy_id << 5) | (reg_num)));
> + tiow(ndev, XTE_CTL0_OFFSET,
> + CNTLREG_WRITE_ENABLE_MASK
> + | XTE_MIIMAI_OFFSET
> + | (lp->emac_num << 10));
> + while (!(status =3D tior(ndev, XTE_RDY0_OFFSET) &
XTE_RSE_MIIM_WR_MASK)) {
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev, "write_MII busy
timeout!!\n");
> + return ;
Seems like this should return -1 as a failure and be consistent with
read().
> + }
> + }
> +
> + spin_unlock_irqrestore(&lp->lock, flags);
> +}
> +
> +static u32
> +emac_cfg_read(struct net_device *ndev, u16 reg_num)
> +{
> + struct temac_local *lp =3D netdev_priv(ndev);
> + u32 timeout =3D PHY_TIMEOUT;
> +
> + if (reg_num > TEMAC_REG_MAX) {
> + dev_err(&ndev->dev,
> + "emac_cfg_read(%x) invalid reg_num\n",
> + reg_num);
> + return -1;
> + }
> +
Can the register value read be -1 by accident such that a valid register
return
looks like a failure?
> + tiow(ndev, XTE_CTL0_OFFSET, (lp->emac_num << 10) | reg_num);
> + while (!(tior(ndev, XTE_RDY0_OFFSET) & XTE_RSE_CFG_RR_MASK)) {
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev, "read temac busy
timeout!!\n");
> + return -1;
> + }
> + }
> + return (u32) tior(ndev, XTE_LSW0_OFFSET);
> +
> +}
> +
> +static void
> +emac_cfg_write(struct net_device *ndev, u32 reg_num, u32 val)
> +{
> + struct temac_local *lp =3D netdev_priv(ndev);
> + u32 timeout =3D PHY_TIMEOUT;
> +
> + if (reg_num > TEMAC_REG_MAX) {
> + dev_err(&ndev->dev,
> + "emac_cfg_write(%x) invalid reg_num\n",
> + reg_num);
> + return -1;
> + }
> +
Same thing returning a value when void return, and timeout below again
should =
return failure? It would seem like these be compiler warnings?
> + tiow(ndev, XTE_LSW0_OFFSET, val);
> + tiow(ndev,
> + XTE_CTL0_OFFSET,
> + (CNTLREG_WRITE_ENABLE_MASK
> + | (lp->emac_num << 10)
> + | reg_num));
> + while (!(tior(ndev, XTE_RDY0_OFFSET) & XTE_RSE_CFG_WR_MASK)) {
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev, "write temac busy
timeout!!\n");
> + return ;
> + }
> + }
> +}
> +
> +static u32
> +emac_cfg_setclr(struct net_device *ndev, u32 reg_num, u32 val, int
flg)
> +{
> + u32 Reg;
> + if (reg_num > TEMAC_REG_MAX) {
> + dev_err(&ndev->dev,
> + "emac_cfg_setclr(%x) invalid reg_num\n",
> + reg_num);
> + return -1;
> + }
Nit.
Sorry to pick on return values so much, but they seem real inconsistent.
seems like an int would be more appropriate here as there's no register
value
to be returned.
> +
> + Reg =3D emac_cfg_read(ndev, reg_num) & ~val;
> + if (flg)
> + Reg |=3D val;
> + emac_cfg_write(ndev, reg_num, Reg);
> + return 0;
> +}
> +
<snip>
> +static int
> +temac_bd_init(struct net_device *ndev)
> +{
> + struct temac_local *lp =3D netdev_priv(ndev);
> + struct sk_buff *skb;
> + int ii;
> +
> + lp->rx_skb =3D kzalloc(sizeof(struct sk_buff)*RX_BD_NUM,
GFP_KERNEL);
> + /* allocate the tx and rx ring buffer descriptors. */
> + /* returns a virtual addres and a physical address. */
> + lp->tx_bd_v =3D dma_alloc_coherent(NULL,
> + sizeof(struct cdmac_bd) * TX_BD_NUM,
> + (dma_addr_t *)&lp->tx_bd_p,
> + GFP_KERNEL);
> + lp->rx_bd_v =3D dma_alloc_coherent(NULL,
> + sizeof(struct cdmac_bd) * RX_BD_NUM,
> + (dma_addr_t *)&lp->rx_bd_p,
> + GFP_KERNEL);
Not sure this is a big deal, BDs have to be cacheline aligned, but since
there are 8 words for each, it's not a problem on 405 and 440 (32 byte
cacheline). Other powerpc processors might be a problem. A more specific
dependency on 4xx might be useful?
> +
> + for (ii =3D 0; ii < TX_BD_NUM; ii++) {
> + memset((char *)&lp->tx_bd_v[ii], 0, sizeof(struct
cdmac_bd));
> + if (ii =3D=3D (TX_BD_NUM - 1))
> + lp->tx_bd_v[ii].next =3D &lp->tx_bd_p[0];
> + else
> + lp->tx_bd_v[ii].next =3D &lp->tx_bd_p[ii + 1];
> +
> + }
<snip>
> +
> +/* Initilize temac */
> +static void
> +temac_device_reset(struct net_device *ndev)
> +{
> + struct temac_local *lp =3D netdev_priv(ndev);
> + u32 timeout =3D 1000;
> +
> + /* Perform a software reset */
> +
> + /* 0x300 host enable bit ? */
> + /* reset PHY through control register ?:1 */
> +
Seems like the above comments should be removed.
> + /* Reset the device */
> + emac_cfg_write(ndev, XTE_RXC1_OFFSET, XTE_RXC1_RXRST_MASK);
> + /* Wait for the receiver to finish reset */
> + while (emac_cfg_read(ndev, XTE_RXC1_OFFSET) &
XTE_RXC1_RXRST_MASK) {
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev,
> + "temac_device_reset RX reset
timeout!!\n");
> + break;
> + }
> + }
> +
> + emac_cfg_write(ndev, XTE_TXC_OFFSET, XTE_TXC_TXRST_MASK);
> + /* Wait for the transmitter to finish reset */
> + timeout =3D 1000;
> + while (emac_cfg_read(ndev, XTE_TXC_OFFSET) & XTE_TXC_TXRST_MASK)
{
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev,
> + "temac_device_reset TX reset
timeout!!\n");
> + break;
> + }
> + }
> +
> + /* Disable the receiver */
> + emac_cfg_write(ndev,
> + XTE_RXC1_OFFSET,
> + emac_cfg_read(ndev, XTE_RXC1_OFFSET)
> + & ~XTE_RXC1_RXEN_MASK);
> +
> + /* reset */
> + tiow(ndev, XTE_RAF0_OFFSET, 1);
> + /* wait for reset */
> + timeout =3D 1000;
> + while (tior(ndev, XTE_RAF0_OFFSET) & 1) {
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev,
> + "temac_device_reset RAF reset
timeout!!\n");
> + break;
> + }
> + }
> +
> + /* ISR0/IER0/IPR0 bits */
> + /* b1 autoneg complete */
> + /* b2 receive complete */
> + /* b5 transmit complete */
> + /* b0 =3D interrupts from TIS/TIE registers */
> +
> +
> + /* Reset */
> + sd_iow(ndev, DMA_CONTROL_REG, DMA_CONTROL_RST);
> + timeout =3D 1000;
> + while (sd_ior(ndev, DMA_CONTROL_REG) & DMA_CONTROL_RST) {
> + udelay(1);
> + if (--timeout =3D=3D 0) {
> + dev_err(&ndev->dev,
> + "temac_device_reset DMA reset
timeout!!\n");
> + break;
> + }
> + }
> +
> + dev_info(&ndev->dev,
> + "%s: Xilinx Embedded Tri-Mode Ethernet MAC %s
%s\n",
> + ndev->name,
> + __DATE__,
> + __TIME__);
> + dev_info(&ndev->dev, "temac %08x sdma %08x\n",
> + lp->regs.addr,
> + lp->sdma.addr);
> +
> + temac_bd_init(ndev);
> +
> + emac_cfg_write(ndev, XTE_RXC0_OFFSET, 0);
> + emac_cfg_write(ndev, XTE_RXC1_OFFSET, 0);
> + emac_cfg_write(ndev, XTE_TXC_OFFSET, 0);
> + emac_cfg_write(ndev, XTE_FCC_OFFSET, XTE_FCC_RXFLO_MASK);
> +
> + /* Sync default options with HW
> + * but leave receiver and transmitter disabled. */
> + temac_setoptions(ndev,
> + lp->options & ~(XTE_OPTION_TXEN |
XTE_OPTION_RXEN));
> +
> + temac_phy_init(ndev);
> +
> + temac_set_mac_address(ndev, 0);
> + /* Set address filter table */
> + temac_set_multicast_list(ndev);
> + if (temac_setoptions(ndev, lp->options))
> + dev_err(&ndev->dev, "Error setting TEMAC options\n");
> +
> + /* Init Driver variable */
> + ndev->trans_start =3D 0;
> + spin_lock_init(&lp->lock);
> + spin_lock_init(&lp->rx_lock);
> +}
> +
> +static void
> +temac_hard_start_xmit_done(struct net_device *ndev)
> +{
> + struct temac_local *lp =3D netdev_priv(ndev);
> + struct cdmac_bd *cur_p;
> + unsigned int stat =3D 0;
> +
> + cur_p =3D &lp->tx_bd_v[lp->tx_bd_ci];
> + stat =3D cur_p->app0;
> +
> + while (stat & STS_CTRL_APP0_CMPLT) {
> + pci_unmap_single(NULL,
> + (unsigned long)cur_p->phys,
> + cur_p->len,
> + PCI_DMA_TODEVICE);
It seems like the PCI calls would be better replaced with
dma_unmap_single() =
and dma_map_single to be more accurate and probably less overhead?
The dma functions, not sure on the pci, should handle when we change the
driver
to cache the BDs as that will be needed eventually for good performance.
> + if (cur_p->app4)
> + dev_kfree_skb_irq((struct sk_buff
*)cur_p->app4);
> + cur_p->app0 =3D 0;
> +
> + lp->stats.tx_packets++;
> + lp->stats.tx_bytes +=3D cur_p->len;
> +
> + lp->tx_bd_ci++;
> + if (lp->tx_bd_ci >=3D TX_BD_NUM)
> + lp->tx_bd_ci =3D 0;
> +
> + cur_p =3D &lp->tx_bd_v[lp->tx_bd_ci];
> + stat =3D cur_p->app0;
> + }
> +
> + netif_wake_queue(ndev);
> +}
> +
<snip>
> +static int __init
> +temac_device_map(struct platform_device *pdev, struct net_device
*ndev,
> + int num, struct temac_region *reg)
> +{
> + struct resource *res;
> + int erC =3D 0;
> +
> + res =3D platform_get_resource(pdev, IORESOURCE_MEM, num);
> + if (res =3D=3D 0) {
> + erC =3D -ENODEV;
> + goto fail;
> + }
> + if (request_mem_region(res->start, res->end - res->start,
> + pdev->name) =3D=3D 0) {
> + dev_err(&pdev->dev,
> + "%s: failed to request registers\n",
> + pdev->name);
> + erC =3D -ENXIO;
> + goto fail;
> + }
> +
> + reg->base =3D (uintptr_t)res->start;
> + reg->len =3D res->end - res->start;
Should this really be res->end - res->start + 1 to include the =
memory region? It's also used up above in the mem_region call.
> + reg->addr =3D ioremap_nocache((uintptr_t)reg->base, reg->len);
> + if (reg->addr =3D=3D 0) {
> + dev_err(&pdev->dev,
> + "%s: failed to remap registers\n", pdev->name);
> + erC =3D -ENXIO;
> + goto fail_remap;
> + }
> + return 0;
> +fail_remap:
> + release_region((u32)reg->addr, reg->len);
> +fail:
> + return erC;
> +}
<snip>
> -----Original Message-----
> From: linuxppc-embedded-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+john.linn=3Dxilinx.com@ozlabs.org] On Behalf Of David H. Lynch
Jr.
> Sent: Tuesday, August 19, 2008 3:34 AM
> To: linuxppc-embedded; netdev@vger.kernel.org
> Subject: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000
EthernetNIC
> =
> Pass II
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: cache model of ppc
From: Scott Wood @ 2008-08-20 18:23 UTC (permalink / raw)
To: Felix Schmidt; +Cc: linuxppc-dev
In-Reply-To: <48AC388D.1090609@web.de>
On Wed, Aug 20, 2008 at 05:30:21PM +0200, Felix Schmidt wrote:
> I some questions about the PowerPC cache model.
>
> How many caches are there?
> How many caches are in multi-core systems? do you have a L1 cache per
> cpu and one shared L2? or is there a victim L3 cache?
>
> can you tell me something about the path through the cache?
> for example I look up for data in L1, but this was a miss. Then i look
> up in L2 this was also a miss. but the date will be in another L1
> cache of another cpu. Is there a 1.5 or 2.5 hit?
This is all dependent on the particular CPU you're talking about, and
should be described in its manual.
-Scott
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Eran Liberty @ 2008-08-20 18:23 UTC (permalink / raw)
To: Jon Smirl
Cc: Mathieu Desnoyers, linux-kernel, Steven Rostedt, linuxppc-dev,
Steven Rostedt, Alan Modra, Scott Wood, Paul E. McKenney
In-Reply-To: <9e4733910808200755y1128ae56p6a1235684bfbb3ec@mail.gmail.com>
Jon Smirl wrote:
> Manually edit the broken binary to change the order of the restore and
> see if the problem disappears. That will keep everything else
> constant.
>
>
checked with objdump where __d_lookup()
> powerpc-linux-gnu-objdump -dr --start-address=0xc0065790 vmlinux |
grep "<__d_lookup>:"
c00b91d8 <__d_lookup>:
> liberty@liberty:~/svn/exsw1600-2.6.27-rc2$ powerpc-linux-gnu-objdump
-dr --start-address=0xc00b91d8 vmlinux| head -n 100
vmlinux: file format elf32-powerpc
Disassembly of section .text:
c00b91d8 <__d_lookup>:
c00b91d8: 7c 08 02 a6 mflr r0
c00b91dc: 90 01 00 04 stw r0,4(r1)
....
c00b92bc: 4e 80 04 21 bctrl
c00b92c0: 2f 83 00 00 cmpwi cr7,r3,0
c00b92c4: 41 9e 00 50 beq- cr7,c00b9314 <__d_lookup+0x13c>
c00b92c8: 83 de 00 00 lwz r30,0(r30)
c00b92cc: 2f 9e 00 00 cmpwi cr7,r30,0
c00b92d0: 40 9e ff 98 bne+ cr7,c00b9268 <__d_lookup+0x90>
c00b92d4: 38 60 00 00 li r3,0
c00b92d8: 81 61 00 00 lwz r11,0(r1)
c00b92dc: 80 0b 00 04 lwz r0,4(r11)
c00b92e0: 7d 61 5b 78 mr r1,r11
<=== As explained by Steve, these two should be replaced ===>
c00b92e4: bb 0b ff e0 lmw r24,-32(r11)
c00b92e8: 7c 08 03 a6 mtlr r0
c00b92ec: 4e 80 00 20 blr
c00b92f0: 80 04 00 04 lwz r0,4(r4)
....
c00b9330: 7f a3 eb 78 mr r3,r29
c00b9334: 4b ff ff a4 b c00b92d8 <__d_lookup+0x100>
c00b9338 <d_lookup>:
c00b9338: 7c 08 02 a6 mflr r0
on the target I fired up xmon and replaced them.
~ # echo x > /proc/sysrq-trigger
SysRq : Entering xmon
Vector: 0 at [df51fdb8]
pc: c0025960: sysrq_handle_xmon+0x60/0x64
lr: c0025960: sysrq_handle_xmon+0x60/0x64
sp: df51fe80
msr: 21000
current = 0xdc22a9a0
pid = 1698, comm = echo
WARNING: exception is not recoverable, can't continue
enter ? for help
[df51fe90] c0193c38 __handle_sysrq+0xa8/0x178
[df51fec0] c00ee818 write_sysrq_trigger+0x78/0x7c
[df51fed0] c00e65e4 proc_reg_write+0x5c/0x84
[df51fef0] c00a299c vfs_write+0xc8/0x180
[df51ff10] c00a2f40 sys_write+0x5c/0xa4
[df51ff40] c0010554 ret_from_syscall+0x0/0x3c
SP (bffe87e0) is in userspace
mon> di c00b92d0
c00b92d0 409eff98 bne cr7,c00b9268 # __d_lookup+0x90/0x160
c00b92d4 38600000 li r3,0
c00b92d8 81610000 lwz r11,0(r1)
c00b92dc 800b0004 lwz r0,4(r11)
c00b92e0 7d615b78 mr r1,r11
<=== wrong order ===>
c00b92e4 bb0bffe0 lmw r24,-32(r11)
c00b92e8 7c0803a6 mtlr r0
c00b92ec 4e800020 blr
c00b92f0 80040004 lwz r0,4(r4)
c00b92f4 7f80c800 cmpw cr7,r0,r25
c00b92f8 409eff64 bne cr7,c00b925c # __d_lookup+0x84/0x160
c00b92fc 80640008 lwz r3,8(r4)
c00b9300 7f25cb78 mr r5,r25
c00b9304 7f04c378 mr r4,r24
c00b9308 4bf5ccf1 bl c0015ff8 # memcmp+0x0/0x30
c00b930c 2f830000 cmpwi cr7,r3,0
mon> m c00b92e0
c00b92e0 7d l
c00b92e0 7d615b78 bb0bffe0
c00b92e4 bb0bffe0 7d615b78
c00b92e8 7c0803a6 x
mon> di c00b92d0
c00b92d0 409eff98 bne cr7,c00b9268 # __d_lookup+0x90/0x160
c00b92d4 38600000 li r3,0
c00b92d8 81610000 lwz r11,0(r1)
c00b92dc 800b0004 lwz r0,4(r11)
c00b92e0 bb0bffe0 lmw r24,-32(r11)
<=== right order ===>
c00b92e4 7d615b78 mr r1,r11
c00b92e8 7c0803a6 mtlr r0
c00b92ec 4e800020 blr
c00b92f0 80040004 lwz r0,4(r4)
c00b92f4 7f80c800 cmpw cr7,r0,r25
c00b92f8 409eff64 bne cr7,c00b925c # __d_lookup+0x84/0x160
c00b92fc 80640008 lwz r3,8(r4)
c00b9300 7f25cb78 mr r5,r25
c00b9304 7f04c378 mr r4,r24
c00b9308 4bf5ccf1 bl c0015ff8 # memcmp+0x0/0x30
c00b930c 2f830000 cmpwi cr7,r3,0
mon> X
~ #
And took it for a test drive
~# while [ 1 ] ; do find / > /dev/null ; echo . ; done
.
.
.
[ 10 min later ]
.
.
.
Stable! Yeepee.
So how do we get this to be right in the first place and everywhere?
-- Liberty
^ permalink raw reply
* Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Hollis Blanchard @ 2008-08-20 18:30 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: linuxppc-dev, kvm-ppc, Arnd Bergmann
In-Reply-To: <48AC13E5.5010503@linux.vnet.ibm.com>
On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote:
>
> Arnd Bergmann wrote:
> > On Tuesday 19 August 2008, ehrhardt@linux.vnet.ibm.com wrote:
> >
> >> Dependent on the already existing CONFIG_KVM_GUEST config option
> this patch
> >> changes wrteei to wrtee allowing the hypervisor to rewrite those to
> nontrapping
> >> instructions. Maybe we should split the kvm guest otpimizations in
> two parts
> >> one for the overhead free optimizations and on for the rest that
> might add
> >> some complexity for non virtualized execution (like this one).
> >>
> >> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> >>
> >
> > How significant is the performance impact of this change for
> non-virtualized
> > systems? If it's very low, maybe you should not bother with the
> #ifdef, and
> > if it's noticable, you might be better off using dynamic patching
> for this.
> >
> > Arnd <><
> >
> To be honest I unfortunately don't know how big the impact for
> non-virtualized systems is. I would like to test it, but without
> hardware performance counters on the core I have I'm not sure (yet)
> how
> to measure that in a good way - any suggestion welcome.
I don't see why we need performance counters. Can't we just compare any
bare metal benchmark results with the patch both applied and not?
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-20 18:33 UTC (permalink / raw)
To: Eran Liberty
Cc: Mathieu Desnoyers, linux-kernel, linuxppc-dev, Steven Rostedt,
Alan Modra, Scott Wood, Paul E. McKenney
In-Reply-To: <48AC6120.1080400@extricom.com>
On Wed, 20 Aug 2008, Eran Liberty wrote:
> mon> X
> ~ #
>
> And took it for a test drive
> ~# while [ 1 ] ; do find / > /dev/null ; echo . ; done
> .
> .
> .
> [ 10 min later ]
> .
> .
> .
>
> Stable! Yeepee.
Eran, thanks a lot for testing this!
>
> So how do we get this to be right in the first place and everywhere?
>
This is a bug in gcc, and should be mentioned to the gcc maintainers.
-- Steve
^ permalink raw reply
* Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Josh Boyer @ 2008-08-20 18:52 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Arnd Bergmann, kvm-ppc, linuxppc-dev
In-Reply-To: <1219257000.14362.90.camel@localhost.localdomain>
On Wed, 2008-08-20 at 13:30 -0500, Hollis Blanchard wrote:
> On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote:
> >
> > Arnd Bergmann wrote:
> > > On Tuesday 19 August 2008, ehrhardt@linux.vnet.ibm.com wrote:
> > >
> > >> Dependent on the already existing CONFIG_KVM_GUEST config option
> > this patch
> > >> changes wrteei to wrtee allowing the hypervisor to rewrite those to
> > nontrapping
> > >> instructions. Maybe we should split the kvm guest otpimizations in
> > two parts
> > >> one for the overhead free optimizations and on for the rest that
> > might add
> > >> some complexity for non virtualized execution (like this one).
> > >>
> > >> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> > >>
> > >
> > > How significant is the performance impact of this change for
> > non-virtualized
> > > systems? If it's very low, maybe you should not bother with the
> > #ifdef, and
> > > if it's noticable, you might be better off using dynamic patching
> > for this.
> > >
> > > Arnd <><
> > >
> > To be honest I unfortunately don't know how big the impact for
> > non-virtualized systems is. I would like to test it, but without
> > hardware performance counters on the core I have I'm not sure (yet)
> > how
> > to measure that in a good way - any suggestion welcome.
>
> I don't see why we need performance counters. Can't we just compare any
> bare metal benchmark results with the patch both applied and not?
Do you know of one that causes a large amount of
local_irq_{disable,enable}s to be called?
josh
^ permalink raw reply
* Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Hollis Blanchard @ 2008-08-20 19:06 UTC (permalink / raw)
To: jwboyer; +Cc: Arnd Bergmann, kvm-ppc, linuxppc-dev
In-Reply-To: <1219258333.26429.29.camel@jdub.homelinux.org>
On Wed, 2008-08-20 at 14:52 -0400, Josh Boyer wrote:
> On Wed, 2008-08-20 at 13:30 -0500, Hollis Blanchard wrote:
> > On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote:
> > >
> > > Arnd Bergmann wrote:
> > > > On Tuesday 19 August 2008, ehrhardt@linux.vnet.ibm.com wrote:
> > > >
> > > >> Dependent on the already existing CONFIG_KVM_GUEST config option
> > > this patch
> > > >> changes wrteei to wrtee allowing the hypervisor to rewrite those to
> > > nontrapping
> > > >> instructions. Maybe we should split the kvm guest otpimizations in
> > > two parts
> > > >> one for the overhead free optimizations and on for the rest that
> > > might add
> > > >> some complexity for non virtualized execution (like this one).
> > > >>
> > > >> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
> > > >>
> > > >
> > > > How significant is the performance impact of this change for
> > > non-virtualized
> > > > systems? If it's very low, maybe you should not bother with the
> > > #ifdef, and
> > > > if it's noticable, you might be better off using dynamic patching
> > > for this.
> > > >
> > > > Arnd <><
> > > >
> > > To be honest I unfortunately don't know how big the impact for
> > > non-virtualized systems is. I would like to test it, but without
> > > hardware performance counters on the core I have I'm not sure (yet)
> > > how
> > > to measure that in a good way - any suggestion welcome.
> >
> > I don't see why we need performance counters. Can't we just compare any
> > bare metal benchmark results with the patch both applied and not?
>
> Do you know of one that causes a large amount of
> local_irq_{disable,enable}s to be called?
I think *every* workload causes a large number of
local_irq_{disable,enable} calls... :)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
From: Josh Boyer @ 2008-08-20 19:18 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: Arnd Bergmann, kvm-ppc, linuxppc-dev
In-Reply-To: <1219259211.14362.94.camel@localhost.localdomain>
On Wed, 20 Aug 2008 14:06:51 -0500
Hollis Blanchard <hollisb@us.ibm.com> wrote:
> > > > To be honest I unfortunately don't know how big the impact for
> > > > non-virtualized systems is. I would like to test it, but without
> > > > hardware performance counters on the core I have I'm not sure (yet)
> > > > how
> > > > to measure that in a good way - any suggestion welcome.
> > >
> > > I don't see why we need performance counters. Can't we just compare any
> > > bare metal benchmark results with the patch both applied and not?
> >
> > Do you know of one that causes a large amount of
> > local_irq_{disable,enable}s to be called?
>
> I think *every* workload causes a large number of
> local_irq_{disable,enable} calls... :)
Well, sure. I was just going for "test the change as specifically as
possible." One could write a module that did X number of
disable/enable pairs and reported the timebase at start and end to
compare. X could even be a module parameter. Just to try and
eliminate noise or whatever from the testing.
/me shrugs.
josh
^ permalink raw reply
* [patch 0/4] PS3 patches for 2.6.27
From: Geoff Levand @ 2008-08-20 20:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
This is a set of PS3 fixup patches for 2.6.27.
Patch 4/4, Fix ioremap of spu shadow regs, is a bit of a hack, but I
can't think of a better way to get the needed protection bits.
[patch 1/4] powerpc: Fix typo in pgtable-ppc64.h
[patch 2/4] powerpc/ps3: Update ps3_defconfig
[patch 3/4] powerpc/ps3: Rework htab to remove ioremap
[patch 4/4] powerpc/ps3: Fix ioremap of spu shadow regs
-Geoff
--
^ permalink raw reply
* [patch 1/4] powerpc: Fix typo in pgtable-ppc64.h
From: Geoff Levand @ 2008-08-20 20:18 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <48AC78BA.3070902@am.sony.com>
Fix a minor comment typo in pgtable-ppc64.h.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -100,7 +100,7 @@
#define _PAGE_WRENABLE (_PAGE_RW | _PAGE_DIRTY)
-/* __pgprot defined in arch/powerpc/incliude/asm/page.h */
+/* __pgprot defined in arch/powerpc/include/asm/page.h */
#define PAGE_NONE __pgprot(_PAGE_PRESENT | _PAGE_ACCESSED)
#define PAGE_SHARED __pgprot(_PAGE_BASE | _PAGE_RW | _PAGE_USER)
--
^ permalink raw reply
* [patch 2/4] powerpc/ps3: Update ps3_defconfig
From: Geoff Levand @ 2008-08-20 20:18 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <48AC78BA.3070902@am.sony.com>
Update ps3_defconfig.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/configs/ps3_defconfig | 153 ++++++++++++++++++++++++++++++++-----
1 file changed, 133 insertions(+), 20 deletions(-)
--- a/arch/powerpc/configs/ps3_defconfig
+++ b/arch/powerpc/configs/ps3_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.26
-# Wed Jul 16 13:59:24 2008
+# Linux kernel version: 2.6.27-rc3
+# Wed Aug 20 08:16:53 2008
#
CONFIG_PPC64=y
@@ -92,7 +92,6 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
-CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
@@ -118,11 +117,16 @@ CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
+CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
+CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
+CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
+# CONFIG_HAVE_CLK is not set
CONFIG_PROC_PAGE_MONITOR=y
+# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
@@ -179,6 +183,7 @@ CONFIG_PS3_STORAGE=y
CONFIG_PS3_DISK=y
CONFIG_PS3_ROM=y
CONFIG_PS3_FLASH=y
+CONFIG_OPROFILE_PS3=y
CONFIG_PS3_LPM=m
CONFIG_PPC_CELL=y
# CONFIG_PPC_CELL_NATIVE is not set
@@ -218,7 +223,7 @@ CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
-# CONFIG_SCHED_HRTICK is not set
+CONFIG_SCHED_HRTICK=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
@@ -252,8 +257,10 @@ CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
# CONFIG_SPARSEMEM_VMEMMAP is not set
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
+# CONFIG_MEMORY_HOTREMOVE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_MIGRATION=y
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
@@ -276,19 +283,17 @@ CONFIG_ISA_DMA_API=y
#
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
+CONFIG_PPC_PCI_CHOICE=y
# CONFIG_PCI is not set
# CONFIG_PCI_DOMAINS is not set
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
# CONFIG_PCCARD is not set
# CONFIG_HAS_RAPIDIO is not set
+# CONFIG_RELOCATABLE is not set
CONFIG_PAGE_OFFSET=0xc000000000000000
CONFIG_KERNEL_START=0xc000000000000000
CONFIG_PHYSICAL_START=0x00000000
-
-#
-# Networking
-#
CONFIG_NET=y
#
@@ -399,9 +404,22 @@ CONFIG_BT_HCIUSB_SCO=y
#
# Wireless
#
-# CONFIG_CFG80211 is not set
+CONFIG_CFG80211=m
+CONFIG_NL80211=y
CONFIG_WIRELESS_EXT=y
-# CONFIG_MAC80211 is not set
+# CONFIG_WIRELESS_EXT_SYSFS is not set
+CONFIG_MAC80211=m
+
+#
+# Rate control algorithm selection
+#
+CONFIG_MAC80211_RC_PID=y
+CONFIG_MAC80211_RC_DEFAULT_PID=y
+CONFIG_MAC80211_RC_DEFAULT="pid"
+# CONFIG_MAC80211_MESH is not set
+# CONFIG_MAC80211_LEDS is not set
+# CONFIG_MAC80211_DEBUGFS is not set
+# CONFIG_MAC80211_DEBUG_MENU is not set
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
@@ -420,14 +438,79 @@ CONFIG_IEEE80211_CRYPT_TKIP=m
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
-CONFIG_FW_LOADER=m
+CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+CONFIG_MTD_DEBUG=y
+CONFIG_MTD_DEBUG_VERBOSE=0
+# CONFIG_MTD_CONCAT is not set
+# CONFIG_MTD_PARTITIONS is not set
+
+#
+# User Modules And Translation Layers
+#
+# CONFIG_MTD_CHAR is not set
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+# CONFIG_MTD_CFI is not set
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+CONFIG_MTD_PS3VRAM=y
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+# CONFIG_MTD_NAND is not set
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
@@ -443,6 +526,7 @@ CONFIG_BLK_DEV_RAM_SIZE=65535
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
+# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
@@ -494,7 +578,6 @@ CONFIG_SCSI_WAIT_SCAN=m
# CONFIG_MD is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
-# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
@@ -510,9 +593,9 @@ CONFIG_MII=m
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_B44 is not set
CONFIG_NETDEV_1000=y
-# CONFIG_E1000E_ENABLED is not set
CONFIG_GELIC_NET=y
CONFIG_GELIC_WIRELESS=y
+CONFIG_GELIC_WIRELESS_OLD_PSK_INTERFACE=y
# CONFIG_NETDEV_10000 is not set
#
@@ -523,8 +606,22 @@ CONFIG_WLAN_80211=y
# CONFIG_LIBERTAS is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
+# CONFIG_RTL8187 is not set
+# CONFIG_MAC80211_HWSIM is not set
+# CONFIG_P54_COMMON is not set
# CONFIG_IWLWIFI_LEDS is not set
# CONFIG_HOSTAP is not set
+# CONFIG_B43 is not set
+# CONFIG_B43LEGACY is not set
+CONFIG_ZD1211RW=m
+# CONFIG_ZD1211RW_DEBUG is not set
+CONFIG_RT2X00=m
+CONFIG_RT2X00_LIB=m
+CONFIG_RT2X00_LIB_USB=m
+CONFIG_RT2X00_LIB_FIRMWARE=y
+# CONFIG_RT2500USB is not set
+CONFIG_RT73USB=m
+# CONFIG_RT2X00_DEBUG is not set
#
# USB Network Adapters
@@ -622,6 +719,7 @@ CONFIG_INPUT_JOYSTICK=y
# Character devices
#
CONFIG_VT=y
+CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
@@ -647,6 +745,8 @@ CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
# CONFIG_SPI is not set
+CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
+# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
@@ -663,8 +763,10 @@ CONFIG_SSB_POSSIBLE=y
#
# Multifunction device drivers
#
+# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
+# CONFIG_MFD_TMIO is not set
#
# Multimedia devices
@@ -796,6 +898,7 @@ CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
+CONFIG_USB_MON=y
#
# USB Host Controller Drivers
@@ -817,6 +920,10 @@ CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_R8A66597_HCD is not set
#
+# Enable Host or Gadget support to see Inventra options
+#
+
+#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
@@ -843,6 +950,7 @@ CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
+# CONFIG_USB_STORAGE_SIERRA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set
@@ -851,7 +959,6 @@ CONFIG_USB_STORAGE=m
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
-CONFIG_USB_MON=y
#
# USB port drivers
@@ -864,7 +971,6 @@ CONFIG_USB_MON=y
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
-# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
@@ -998,9 +1104,11 @@ CONFIG_HUGETLB_PAGE=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
+# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
+# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
@@ -1011,14 +1119,13 @@ CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=y
-# CONFIG_NFSD is not set
CONFIG_ROOT_NFS=y
+# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
-# CONFIG_SUNRPC_BIND34 is not set
CONFIG_RPCSEC_GSS_KRB5=y
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
@@ -1086,7 +1193,7 @@ CONFIG_BITREVERSE=y
# CONFIG_GENERIC_FIND_FIRST_BIT is not set
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
-# CONFIG_CRC_T10DIF is not set
+CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
@@ -1115,6 +1222,8 @@ CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
+# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
@@ -1138,6 +1247,7 @@ CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
CONFIG_DEBUG_WRITECOUNT=y
+CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
CONFIG_FRAME_POINTER=y
@@ -1146,6 +1256,7 @@ CONFIG_FRAME_POINTER=y
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
+CONFIG_SYSCTL_SYSCALL_CHECK=y
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
# CONFIG_FTRACE is not set
@@ -1153,12 +1264,14 @@ CONFIG_HAVE_DYNAMIC_FTRACE=y
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_SAMPLES is not set
+CONFIG_HAVE_ARCH_KGDB=y
+# CONFIG_KGDB is not set
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
-# CONFIG_DEBUGGER is not set
# CONFIG_CODE_PATCHING_SELFTEST is not set
# CONFIG_FTR_FIXUP_SELFTEST is not set
+# CONFIG_XMON is not set
CONFIG_IRQSTACKS=y
# CONFIG_VIRQ_DEBUG is not set
# CONFIG_BOOTX_TEXT is not set
--
^ permalink raw reply
* [patch 4/4] powerpc/ps3: Fix ioremap of spu shadow regs
From: Geoff Levand @ 2008-08-20 20:18 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <48AC78BA.3070902@am.sony.com>
From: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Fix the ioremap of the spu shadow regs on the PS3.
The current PS3 hypervisor requires the spu shadow regs to be
mapped with the PTE page protection bits set as read-only (PP=3).
This implementation uses the low level __ioremap() to bypass the
page protection settings inforced by ioremap_flags() to get the
needed PTE bits set for the shadow regs.
This fixes a runtime failure on the PS3 introduced by the powerpc
ioremap_prot rework of commit a1f242ff460e4b50a045fa237c3c56cce9eabf83.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/spu.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -186,14 +186,24 @@ static void spu_unmap(struct spu *spu)
iounmap(spu_pdata(spu)->shadow);
}
+/**
+ * setup_areas - Map the spu regions into the address space.
+ *
+ * The current HV requires the spu shadow regs to be mapped with the
+ * PTE page protection bits set as read-only (PP=3). This implementation
+ * uses the low level __ioremap() to bypass the page protection settings
+ * inforced by ioremap_flags() to get the needed PTE bits set for the
+ * shadow regs.
+ */
+
static int __init setup_areas(struct spu *spu)
{
struct table {char* name; unsigned long addr; unsigned long size;};
+ static const unsigned long shadow_flags = _PAGE_NO_CACHE | 3;
- spu_pdata(spu)->shadow = ioremap_flags(spu_pdata(spu)->shadow_addr,
- sizeof(struct spe_shadow),
- pgprot_val(PAGE_READONLY) |
- _PAGE_NO_CACHE);
+ spu_pdata(spu)->shadow = __ioremap(spu_pdata(spu)->shadow_addr,
+ sizeof(struct spe_shadow),
+ shadow_flags);
if (!spu_pdata(spu)->shadow) {
pr_debug("%s:%d: ioremap shadow failed\n", __func__, __LINE__);
goto fail_ioremap;
--
^ permalink raw reply
* [patch 3/4] powerpc/ps3: Rework htab to remove ioremap
From: Geoff Levand @ 2008-08-20 20:18 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <48AC78BA.3070902@am.sony.com>
From: Masakazu Mokuno <mokuno@sm.sony.co.jp>
Rework the PS3 htab code to remove the need to ioremap the hash table
by using the HV calls lv1_insert_htab_entry() and
lv1_read_htab_entries().
This fixes a runtime failure on the PS3 introduced by the powerpc
ioremap_prot rework of commit a1f242ff460e4b50a045fa237c3c56cce9eabf83.
Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/platforms/ps3/htab.c | 269 ++++++++++++-------------------------
arch/powerpc/platforms/ps3/setup.c | 1
2 files changed, 91 insertions(+), 179 deletions(-)
--- a/arch/powerpc/platforms/ps3/htab.c
+++ b/arch/powerpc/platforms/ps3/htab.c
@@ -29,138 +29,75 @@
#include "platform.h"
-#if defined(DEBUG)
-#define DBG udbg_printf
-#else
-#define DBG pr_debug
-#endif
-
-static struct hash_pte *htab;
-static unsigned long htab_addr;
-static unsigned char *bolttab;
-static unsigned char *inusetab;
-
-static DEFINE_SPINLOCK(ps3_bolttab_lock);
-
-#define debug_dump_hpte(_a, _b, _c, _d, _e, _f, _g) \
- _debug_dump_hpte(_a, _b, _c, _d, _e, _f, _g, __func__, __LINE__)
-static void _debug_dump_hpte(unsigned long pa, unsigned long va,
- unsigned long group, unsigned long bitmap, struct hash_pte lhpte,
- int psize, unsigned long slot, const char* func, int line)
-{
- DBG("%s:%d: pa = %lxh\n", func, line, pa);
- DBG("%s:%d: lpar = %lxh\n", func, line,
- ps3_mm_phys_to_lpar(pa));
- DBG("%s:%d: va = %lxh\n", func, line, va);
- DBG("%s:%d: group = %lxh\n", func, line, group);
- DBG("%s:%d: bitmap = %lxh\n", func, line, bitmap);
- DBG("%s:%d: hpte.v = %lxh\n", func, line, lhpte.v);
- DBG("%s:%d: hpte.r = %lxh\n", func, line, lhpte.r);
- DBG("%s:%d: psize = %xh\n", func, line, psize);
- DBG("%s:%d: slot = %lxh\n", func, line, slot);
-}
+/**
+ * enum lpar_vas_id - id of LPAR virtual address space.
+ * @lpar_vas_id_current: Current selected virtual address space
+ *
+ * Identify the target LPAR address space.
+ */
+
+enum ps3_lpar_vas_id {
+ PS3_LPAR_VAS_ID_CURRENT = 0,
+};
+
+
+static DEFINE_SPINLOCK(ps3_htab_lock);
static long ps3_hpte_insert(unsigned long hpte_group, unsigned long va,
unsigned long pa, unsigned long rflags, unsigned long vflags,
int psize, int ssize)
{
- unsigned long slot;
- struct hash_pte lhpte;
- int secondary = 0;
- unsigned long result;
- unsigned long bitmap;
+ int result;
+ u64 hpte_v, hpte_r;
+ u64 inserted_index;
+ u64 evicted_v, evicted_r;
+ u64 hpte_v_array[4], hpte_rs;
unsigned long flags;
- unsigned long p_pteg, s_pteg, b_index, b_mask, cb, ci;
-
- vflags &= ~HPTE_V_SECONDARY; /* this bit is ignored */
+ long ret = -1;
- lhpte.v = hpte_encode_v(va, psize, MMU_SEGSIZE_256M) |
- vflags | HPTE_V_VALID;
- lhpte.r = hpte_encode_r(ps3_mm_phys_to_lpar(pa), psize) | rflags;
-
- p_pteg = hpte_group / HPTES_PER_GROUP;
- s_pteg = ~p_pteg & htab_hash_mask;
-
- spin_lock_irqsave(&ps3_bolttab_lock, flags);
+ /*
+ * lv1_insert_htab_entry() will search for victim
+ * entry in both primary and secondary pte group
+ */
+ vflags &= ~HPTE_V_SECONDARY;
- BUG_ON(bolttab[p_pteg] == 0xff && bolttab[s_pteg] == 0xff);
+ hpte_v = hpte_encode_v(va, psize, ssize) | vflags | HPTE_V_VALID;
+ hpte_r = hpte_encode_r(ps3_mm_phys_to_lpar(pa), psize) | rflags;
- bitmap = (inusetab[p_pteg] << 8) | inusetab[s_pteg];
+ spin_lock_irqsave(&ps3_htab_lock, flags);
- if (bitmap == 0xffff) {
- /*
- * PTEG is full. Search for victim.
- */
- bitmap &= ~((bolttab[p_pteg] << 8) | bolttab[s_pteg]);
- do {
- ci = mftb() & 15;
- cb = 0x8000UL >> ci;
- } while ((cb & bitmap) == 0);
- } else {
- /*
- * search free slot in hardware order
- * [primary] 0, 2, 4, 6, 1, 3, 5, 7
- * [secondary] 0, 2, 4, 6, 1, 3, 5, 7
- */
- for (ci = 0; ci < HPTES_PER_GROUP; ci += 2) {
- cb = 0x8000UL >> ci;
- if ((cb & bitmap) == 0)
- goto found;
- }
- for (ci = 1; ci < HPTES_PER_GROUP; ci += 2) {
- cb = 0x8000UL >> ci;
- if ((cb & bitmap) == 0)
- goto found;
- }
- for (ci = HPTES_PER_GROUP; ci < HPTES_PER_GROUP*2; ci += 2) {
- cb = 0x8000UL >> ci;
- if ((cb & bitmap) == 0)
- goto found;
- }
- for (ci = HPTES_PER_GROUP+1; ci < HPTES_PER_GROUP*2; ci += 2) {
- cb = 0x8000UL >> ci;
- if ((cb & bitmap) == 0)
- goto found;
- }
- }
-
-found:
- if (ci < HPTES_PER_GROUP) {
- slot = p_pteg * HPTES_PER_GROUP + ci;
- } else {
- slot = s_pteg * HPTES_PER_GROUP + (ci & 7);
- /* lhpte.dw0.dw0.h = 1; */
- vflags |= HPTE_V_SECONDARY;
- lhpte.v |= HPTE_V_SECONDARY;
- }
-
- result = lv1_write_htab_entry(0, slot, lhpte.v, lhpte.r);
+ /* talk hvc to replace entries BOLTED == 0 */
+ result = lv1_insert_htab_entry(PS3_LPAR_VAS_ID_CURRENT, hpte_group,
+ hpte_v, hpte_r,
+ HPTE_V_BOLTED, 0,
+ &inserted_index,
+ &evicted_v, &evicted_r);
if (result) {
- debug_dump_hpte(pa, va, hpte_group, bitmap, lhpte, psize, slot);
+ /* all entries bolted !*/
+ pr_info("%s:result=%d va=%lx pa=%lx ix=%lx v=%lx r=%lx\n",
+ __func__, result, va, pa, hpte_group, hpte_v, hpte_r);
BUG();
}
/*
- * If used slot is not in primary HPTE group,
- * the slot should be in secondary HPTE group.
+ * see if the entry is inserted into secondary pteg
*/
+ result = lv1_read_htab_entries(PS3_LPAR_VAS_ID_CURRENT,
+ inserted_index & ~0x3UL,
+ &hpte_v_array[0], &hpte_v_array[1],
+ &hpte_v_array[2], &hpte_v_array[3],
+ &hpte_rs);
+ BUG_ON(result);
- if ((hpte_group ^ slot) & ~(HPTES_PER_GROUP - 1)) {
- secondary = 1;
- b_index = s_pteg;
- } else {
- secondary = 0;
- b_index = p_pteg;
- }
+ if (hpte_v_array[inserted_index % 4] & HPTE_V_SECONDARY)
+ ret = (inserted_index & 7) | (1 << 3);
+ else
+ ret = inserted_index & 7;
- b_mask = (lhpte.v & HPTE_V_BOLTED) ? 1 << 7 : 0 << 7;
- bolttab[b_index] |= b_mask >> (slot & 7);
- b_mask = 1 << 7;
- inusetab[b_index] |= b_mask >> (slot & 7);
- spin_unlock_irqrestore(&ps3_bolttab_lock, flags);
+ spin_unlock_irqrestore(&ps3_htab_lock, flags);
- return (slot & 7) | (secondary << 3);
+ return ret;
}
static long ps3_hpte_remove(unsigned long hpte_group)
@@ -172,39 +109,48 @@ static long ps3_hpte_remove(unsigned lon
static long ps3_hpte_updatepp(unsigned long slot, unsigned long newpp,
unsigned long va, int psize, int ssize, int local)
{
+ int result;
+ u64 hpte_v, want_v, hpte_rs;
+ u64 hpte_v_array[4];
unsigned long flags;
- unsigned long result;
- unsigned long pteg, bit;
- unsigned long hpte_v, want_v;
-
- want_v = hpte_encode_v(va, psize, MMU_SEGSIZE_256M);
+ long ret;
- spin_lock_irqsave(&ps3_bolttab_lock, flags);
-
- hpte_v = htab[slot].v;
- if (!HPTE_V_COMPARE(hpte_v, want_v) || !(hpte_v & HPTE_V_VALID)) {
- spin_unlock_irqrestore(&ps3_bolttab_lock, flags);
+ want_v = hpte_encode_v(va, psize, ssize);
- /* ps3_hpte_insert() will be used to update PTE */
- return -1;
- }
+ spin_lock_irqsave(&ps3_htab_lock, flags);
- result = lv1_write_htab_entry(0, slot, 0, 0);
+ result = lv1_read_htab_entries(PS3_LPAR_VAS_ID_CURRENT, slot & ~0x3UL,
+ &hpte_v_array[0], &hpte_v_array[1],
+ &hpte_v_array[2], &hpte_v_array[3],
+ &hpte_rs);
if (result) {
- DBG("%s: va=%lx slot=%lx psize=%d result = %ld (0x%lx)\n",
- __func__, va, slot, psize, result, result);
+ pr_info("%s: res=%d read va=%lx slot=%lx psize=%d\n",
+ __func__, result, va, slot, psize);
BUG();
}
- pteg = slot / HPTES_PER_GROUP;
- bit = slot % HPTES_PER_GROUP;
- inusetab[pteg] &= ~(0x80 >> bit);
+ hpte_v = hpte_v_array[slot % 4];
- spin_unlock_irqrestore(&ps3_bolttab_lock, flags);
+ /*
+ * As lv1_read_htab_entries() does not give us the RPN, we can
+ * not synthesize the new hpte_r value here, and therefore can
+ * not update the hpte with lv1_insert_htab_entry(), so we
+ * insted invalidate it and ask the caller to update it via
+ * ps3_hpte_insert() by returning a -1 value.
+ */
+ if (!HPTE_V_COMPARE(hpte_v, want_v) || !(hpte_v & HPTE_V_VALID)) {
+ /* not found */
+ ret = -1;
+ } else {
+ /* entry found, just invalidate it */
+ result = lv1_write_htab_entry(PS3_LPAR_VAS_ID_CURRENT,
+ slot, 0, 0);
+ ret = -1;
+ }
- /* ps3_hpte_insert() will be used to update PTE */
- return -1;
+ spin_unlock_irqrestore(&ps3_htab_lock, flags);
+ return ret;
}
static void ps3_hpte_updateboltedpp(unsigned long newpp, unsigned long ea,
@@ -217,45 +163,35 @@ static void ps3_hpte_invalidate(unsigned
int psize, int ssize, int local)
{
unsigned long flags;
- unsigned long result;
- unsigned long pteg, bit;
+ int result;
+
+ spin_lock_irqsave(&ps3_htab_lock, flags);
- spin_lock_irqsave(&ps3_bolttab_lock, flags);
- result = lv1_write_htab_entry(0, slot, 0, 0);
+ result = lv1_write_htab_entry(PS3_LPAR_VAS_ID_CURRENT, slot, 0, 0);
if (result) {
- DBG("%s: va=%lx slot=%lx psize=%d result = %ld (0x%lx)\n",
- __func__, va, slot, psize, result, result);
+ pr_info("%s: res=%d va=%lx slot=%lx psize=%d\n",
+ __func__, result, va, slot, psize);
BUG();
}
- pteg = slot / HPTES_PER_GROUP;
- bit = slot % HPTES_PER_GROUP;
- inusetab[pteg] &= ~(0x80 >> bit);
- spin_unlock_irqrestore(&ps3_bolttab_lock, flags);
+ spin_unlock_irqrestore(&ps3_htab_lock, flags);
}
static void ps3_hpte_clear(void)
{
- int result;
+ unsigned long hpte_count = (1UL << ppc64_pft_size) >> 4;
+ u64 i;
- DBG(" -> %s:%d\n", __func__, __LINE__);
-
- result = lv1_unmap_htab(htab_addr);
- BUG_ON(result);
+ for (i = 0; i < hpte_count; i++)
+ lv1_write_htab_entry(PS3_LPAR_VAS_ID_CURRENT, i, 0, 0);
ps3_mm_shutdown();
ps3_mm_vas_destroy();
-
- DBG(" <- %s:%d\n", __func__, __LINE__);
}
void __init ps3_hpte_init(unsigned long htab_size)
{
- long bitmap_size;
-
- DBG(" -> %s:%d\n", __func__, __LINE__);
-
ppc_md.hpte_invalidate = ps3_hpte_invalidate;
ppc_md.hpte_updatepp = ps3_hpte_updatepp;
ppc_md.hpte_updateboltedpp = ps3_hpte_updateboltedpp;
@@ -264,28 +200,5 @@ void __init ps3_hpte_init(unsigned long
ppc_md.hpte_clear_all = ps3_hpte_clear;
ppc64_pft_size = __ilog2(htab_size);
-
- bitmap_size = htab_size / sizeof(struct hash_pte) / 8;
-
- bolttab = __va(lmb_alloc(bitmap_size, 1));
- inusetab = __va(lmb_alloc(bitmap_size, 1));
-
- memset(bolttab, 0, bitmap_size);
- memset(inusetab, 0, bitmap_size);
-
- DBG(" <- %s:%d\n", __func__, __LINE__);
}
-void __init ps3_map_htab(void)
-{
- long result;
- unsigned long htab_size = (1UL << ppc64_pft_size);
-
- result = lv1_map_htab(0, &htab_addr);
-
- htab = (__force struct hash_pte *)ioremap_flags(htab_addr, htab_size,
- pgprot_val(PAGE_READONLY_X));
-
- DBG("%s:%d: lpar %016lxh, virt %016lxh\n", __func__, __LINE__,
- htab_addr, (unsigned long)htab);
-}
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -201,7 +201,6 @@ static void __init ps3_setup_arch(void)
ps3_firmware_version.rev);
ps3_spu_set_platform();
- ps3_map_htab();
#ifdef CONFIG_SMP
smp_init_ps3();
--
^ permalink raw reply
* Strange behavior with I2C on Sequoia board
From: Steven A. Falco @ 2008-08-20 20:55 UTC (permalink / raw)
To: linuxppc-dev
I have just tried enabling I2C on a Sequoia board (kernel is DENX 2.6.26) and
doing that appears to corrupt the u-boot / kernel communications.
Prior to turning on I2C, I see the ethernet mac and kernel command line
correctly passed, but once I turn on I2C, the ethernet mac becomes 0 and the
kernel command line is missing many parameters. I'll paste in a good log, then
a bad one. The only configuration difference is that the bad one has
CONFIG_I2C_CHARDEV=y and CONFIG_I2C_IBM_IIC=y in the configuration.
I'll start digging into it, but if anyone has any experience or ideas regarding
I2C on PPC440, I'd appreciate your thoughts on this.
Steve
Good log:
=========
## Booting kernel from Legacy Image at fd400000 ...
Image Name: Linux-2.6.26.1-00033-g088efe4-di
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1801234 Bytes = 1.7 MB
Load Address: 00400000
Entry Point: 00400454
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading init Ramdisk from Legacy Image at fd900000 ...
Image Name: initramfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 2442283 Bytes = 2.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK
CPU clock-frequency <- 0x27bc86a4 (667MHz)
CPU timebase-frequency <- 0x27bc86a4 (667MHz)
/plb: clock-frequency <- 9ef21a9 (167MHz)
/plb/opb: clock-frequency <- 4f790d4 (83MHz)
/plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz)
/plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600500: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600600: clock-frequency <- a8c000 (11MHz)
Memory <- <0x0 0x0 0xffff000> (255MB)
ENET0: local-mac-address <- 00:10:ec:01:04:d0
ENET1: local-mac-address <- 00:10:ec:01:04:d1
zImage starting: loaded at 0x00400000 (sp: 0x0ff0d220)
Allocating 0x3dbc2c bytes for kernel ...
gunzipping (0x00000000 <- 0x0040e000:0x007ed9c8)...done 0x39c1c4 bytes
Using loader supplied ramdisk at 0xfcb8000-0xff0c42b
initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/sda3 rw
ip=137.237.178.105:137.237.179.31:137.237.178.1:255.255.255.0:hydra_temp:eth0:off
panic=1 console=ttyS0,115200
Bad log:
========
## Booting kernel from Legacy Image at fd400000 ...
Image Name: Linux-2.6.26.1-00034-gf084326-di
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1811651 Bytes = 1.7 MB
Load Address: 00400000
Entry Point: 00400454
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading init Ramdisk from Legacy Image at fd900000 ...
Image Name: initramfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 2442283 Bytes = 2.3 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK
CPU clock-frequency <- 0x27bc86a4 (667MHz)
CPU timebase-frequency <- 0x27bc86a4 (667MHz)
/plb: clock-frequency <- 9ef21a9 (167MHz)
/plb/opb: clock-frequency <- 4f790d4 (83MHz)
/plb/opb/ebc: clock-frequency <- 34fb5e3 (56MHz)
/plb/opb/serial@ef600300: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600400: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600500: clock-frequency <- a8c000 (11MHz)
/plb/opb/serial@ef600600: clock-frequency <- a8c000 (11MHz)
Memory <- <0x0 0x0 0xffff000> (255MB)
ENET0: local-mac-address <- 00:00:00:00:00:00
ENET1: local-mac-address <- 00:00:00:00:00:00
zImage starting: loaded at 0x00400000 (sp: 0x0ff0d220)
Allocating 0x3e1c48 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040e000:0x007f3a24)...done 0x3a21c4 bytes
Using loader supplied ramdisk at 0xfcb8000-0xff0c42b
initrd head: 0x1f8b0808
Linux/PowerPC load: console=ttyS0,115200
^ permalink raw reply
* Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errrata
From: Vitaly Bordug @ 2008-08-20 21:03 UTC (permalink / raw)
To: benh
Cc: linuxppc-dev@ozlabs.org, Stefan Roese,
linux-usb-devel@lists.sourceforge.net, Mark Miesfeld
In-Reply-To: <1219111423.8062.10.camel@pasglop>
В Tue, 19 Aug 2008 12:03:42 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> пишет:
>
> .../...
>
> > There is a software workaround that uses a trick to detect if
> > full-speed interface is enabled from the hi-speed driver(and vice
> > versa), and use suspend control for ohci to enable/disable it
> > appropriately.
> > Initial version of the software workaround was posted to
> > linux-usb-devel:
> >
> > http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
> >
> > and later were made available from amcc.com:
> > http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
> >
> > The patch below is generally based on the latter, but reworked to
> > powerpc/of_device USB drivers, and uses a few devicetree inquiries
> > to get rid of (some) hardcoded defines.
>
> Well, it seems to still call things based on #ifdef CONFIG_* instead
> of testing for whatever "errata" bit or flag you can initialize.
>
> A proper approach is to have the OF probe code detect via some
> device-tree compatible testing or such, that it's indeed hitting the
> broken chip, use that to set a quirk in the controller, and then
> have the core ehci-hub.c code do whatever it has to do based on
> the presence of that quirk.
Makes sense, thanks. I'll look into rearranging stuff appropriately
over this weekend.
Thanks,
-Vitaly
^ permalink raw reply
* [RFC] mtd: add OF2PDEV convertor for the NDFC driver
From: Sebastian Siewior @ 2008-08-20 20:59 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, tglx, linux-mtd
I didn't convert the NDFC driver to support OF because there are
non-OF-aware platforms with the ndfc chip.
All settings are mandatory except the oob layout.
Signed-off-by: Sebastian Siewior <bigeasy@linutronix.de>
---
drivers/mtd/nand/Kconfig | 7 ++
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/ndfc_of.c | 253 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 261 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/ndfc_of.c
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index ab0d77e..5bf0a25 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -170,6 +170,13 @@ config MTD_NAND_NDFC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
+config MTD_NAND_NDFC_OF
+ tristate "OF support for NDFC"
+ depends on MTD_NAND_NDFC && PPC_OF
+ help
+ This setting allows to read the NanD configuration from OF instead
+ of a Platform device.
+
config MTD_NAND_S3C2410_CLKSTOP
bool "S3C2410 NAND IDLE clock stop"
depends on MTD_NAND_S3C2410
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index b786c5d..5a9da0f 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_MTD_NAND_TS7250) += ts7250.o
obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o
obj-$(CONFIG_MTD_NAND_CS553X) += cs553x_nand.o
obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o
+obj-$(CONFIG_MTD_NAND_NDFC_OF) += ndfc_of.o
obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o
obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o
obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) += excite_nandflash.o
diff --git a/drivers/mtd/nand/ndfc_of.c b/drivers/mtd/nand/ndfc_of.c
new file mode 100644
index 0000000..852dca3
--- /dev/null
+++ b/drivers/mtd/nand/ndfc_of.c
@@ -0,0 +1,253 @@
+/*
+ * OF -> Platform device wrapper for NDFC
+ * (c) Sebastian Siewior, Linutronix
+ */
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/mtd/partitions.h>
+#include <linux/mtd/nand.h>
+#include <linux/mtd/ndfc.h>
+
+struct resource ndfc_resource;
+
+struct ndfc_controller_settings ndfc_settings;
+
+struct platform_nand_ctrl ndfc_nand_ctrl = {
+ .priv = &ndfc_settings,
+};
+
+static struct platform_device ndfc_nand_device = {
+ .name = "ndfc-nand",
+ .id = 0,
+ .dev = {
+ .platform_data = &ndfc_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = &ndfc_resource,
+};
+
+static int ndfc_num_devices;
+
+struct of_ndfc_devices {
+ struct platform_device device;
+ struct platform_nand_chip chip;
+ struct ndfc_chip_settings chip_settings;
+ struct nand_ecclayout ecclayout;
+};
+
+static struct of_ndfc_devices *ndfc_chips;
+
+static int __devinit of_nand_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct device_node *dp = dev->node;
+ struct device_node *child_node;
+ const u32 *u32_val;
+ int ret;
+ int i;
+ u32 len;
+ u32 ccr_bank;
+ u32 read_cycles;
+ u32 num_chips = 0;
+
+ ret = of_address_to_resource(dp, 0, &ndfc_resource);
+ if (ret) {
+ dev_err(&dev->dev, "Failed to read address from DT.\n");
+ return ret;
+ }
+
+ u32_val = of_get_property(dp, "id", &len);
+ if (!u32_val || len != 4) {
+ dev_err(&dev->dev, "Failed to read property: id\n");
+ return -EINVAL;
+ }
+ ndfc_nand_device.id = *u32_val;
+
+ u32_val = of_get_property(dp, "ccr_bank", &len);
+ if (!u32_val || len != 4) {
+ dev_err(&dev->dev, "Failed to read property: ccr_bank\n");
+ return -EINVAL;
+ }
+ ccr_bank = *u32_val;
+
+ u32_val = of_get_property(dp, "read_cycles", &len);
+ if (!u32_val || len != 4) {
+ dev_err(&dev->dev, "Failed to read property: read_cycles\n");
+ return -EINVAL;
+ }
+ read_cycles = *u32_val;
+
+ ndfc_settings.ccr_settings = NDFC_CCR_BS(ccr_bank) | read_cycles;
+
+ u32_val = of_get_property(dp, "erpn", &len);
+ if (!u32_val || len != 4) {
+ dev_err(&dev->dev, "Failed to read property: erpn\n");
+ return -EINVAL;
+ }
+ ndfc_settings.ndfc_erpn = *u32_val;
+
+ for_each_child_of_node(dp, child_node)
+ num_chips++;
+
+ if (!num_chips) {
+ dev_err(&dev->dev, "Failed to find chip nodes\n");
+ return -EINVAL;
+ }
+
+ ndfc_num_devices = num_chips;
+ ndfc_chips = kzalloc(ndfc_num_devices * sizeof(struct of_ndfc_devices),
+ GFP_KERNEL);
+ if (!ndfc_chips) {
+ dev_err(&dev->dev, "OOM while allocating memory for %d "
+ "ndfc_chips\n", num_chips);
+ return -ENOMEM;
+ }
+
+ num_chips = 0;
+ for_each_child_of_node(dp, child_node) {
+ struct of_ndfc_devices *cur_dev;
+ struct mtd_partition *partitions;
+ int num_part;
+
+ BUG_ON(num_chips > ndfc_num_devices);
+ cur_dev = &ndfc_chips[num_chips];
+
+ num_part = of_mtd_parse_partitions(&dev->dev, child_node,
+ &partitions);
+ if (num_part < 0) {
+ dev_err(&dev->dev, "Failed to parse partition table %d "
+ "from OF\n", num_chips);
+ goto out_err;
+ }
+
+ u32_val = of_get_property(child_node, "chipoffset", &len);
+ if (!u32_val || len != 4) {
+ dev_err(&dev->dev, "Failed to read property: chipoffset\n");
+ goto out_err;
+ }
+ cur_dev->chip.chip_offset = *u32_val;
+
+ u32_val = of_get_property(child_node, "delay", &len);
+ if (!u32_val || len != 4) {
+ dev_err(&dev->dev, "Failed to read property: delay\n");
+ goto out_err;
+ }
+ cur_dev->chip.chip_delay = *u32_val;
+
+ u32_val = of_get_property(child_node, "banksettings", &len);
+ if (!u32_val || len != 4) {
+ dev_err(&dev->dev, "Failed to read property: banksettings\n");
+ goto out_err;
+ }
+ cur_dev->chip_settings.bank_settings = *u32_val;
+
+ cur_dev->device.name = "ndfc-chip";
+ cur_dev->device.id = num_chips;
+ cur_dev->device.num_resources = 1;
+ cur_dev->device.resource = &ndfc_resource;
+
+ cur_dev->device.dev.platform_data = &cur_dev->chip;
+ cur_dev->device.dev.parent = &ndfc_nand_device.dev;
+
+ u32_val = of_get_property(child_node, "eccbytes", &len);
+ if (!u32_val)
+ goto skip_oob_data;
+
+ cur_dev->ecclayout.eccbytes = *u32_val;
+
+ u32_val = of_get_property(child_node, "eccpos", &len);
+ if (!u32_val)
+ goto skip_oob_data;
+
+ len /= sizeof(u32);
+ if (len > 64)
+ goto skip_oob_data;
+
+ for (i = 0; i < len; i++)
+ cur_dev->ecclayout.eccpos[i] = u32_val[i];
+
+ u32_val = of_get_property(child_node, "oobfree", &len);
+ if (!u32_val)
+ goto skip_oob_data;
+
+ len /= sizeof(u32);
+ if (len & 1)
+ goto skip_oob_data;
+
+ if (len / 2 > MTD_MAX_OOBFREE_ENTRIES)
+ goto skip_oob_data;
+
+ for (i = 0; i < len; i += 2) {
+ cur_dev->ecclayout.oobfree[i / 2].offset =
+ u32_val[i];
+ cur_dev->ecclayout.oobfree[i / 2].length =
+ u32_val[i + 1];
+ }
+
+ cur_dev->chip.ecclayout = &cur_dev->ecclayout;
+skip_oob_data:
+ cur_dev->chip.nr_partitions = num_part;
+ cur_dev->chip.partitions = partitions;
+
+ cur_dev->chip.priv = &cur_dev->chip_settings;
+
+ num_chips++;
+ }
+
+ platform_device_register(&ndfc_nand_device);
+ for (i = 0; i < ndfc_num_devices; i++)
+ platform_device_register(&ndfc_chips[i].device);
+ return 0;
+
+out_err:
+ for (i = 0; i < num_chips; i++)
+ kfree(ndfc_chips[i].chip.partitions);
+ kfree(ndfc_chips);
+ ndfc_chips = NULL;
+ return -EINVAL;
+}
+
+static int of_nand_remove(struct of_device *dev)
+{
+ int i;
+
+ for (i = 0; i < ndfc_num_devices; i++)
+ platform_device_unregister(&ndfc_chips[i].device);
+ platform_device_unregister(&ndfc_nand_device);
+ kfree(ndfc_chips);
+ ndfc_chips = NULL;
+ return 0;
+}
+
+static struct of_device_id of_nand_match[] = {
+ {
+ .compatible = "ibm,ndfc",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, of_nand_match);
+
+static struct of_platform_driver of_flash_driver = {
+ .name = "of-ibm-ndfc",
+ .match_table = of_nand_match,
+ .probe = of_nand_probe,
+ .remove = of_nand_remove,
+};
+
+static int __init agco_nand_init(void)
+{
+ return of_register_platform_driver(&of_flash_driver);
+}
+
+static void __exit agco_nand_exit(void)
+{
+ of_unregister_platform_driver(&of_flash_driver);
+}
+
+module_init(agco_nand_init);
+module_exit(agco_nand_exit);
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Sebastian Siewior <bigeasy@linutronix.de>");
+MODULE_DESCRIPTION("OF 2 PDEV converter for ndfc");
--
1.5.5.2
^ permalink raw reply related
* Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
From: Roland Dreier @ 2008-08-20 21:15 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Arnd, Bergmann
In-Reply-To: <20080820133500.1b15fb0a@zod.rchland.ibm.com>
> > Yeah, I wasn't clear -- I meant to add a new helper like
> > of_flat_dt_is_compatible_list() (not sure of the name) that takes a node
> > and a NULL-terminated array of strings, and then mpc5200_simple_probe()
> > can become a one-liner, along with mpc5121_generic_probe(),
> > tqm85xx_probe(), ppc44x_probe(), etc.
> I worry about doing that though. I don't want to give people the
> impression that these boards are "of" compatible. I want it to be more
> "this file supports these explicit platforms and makes no claim on
> compatibility between them".
It's no big deal really -- just my knee-jerk reaction to seeing a
comment like "this should also be fixed in some other place because I
copied the code from there." My reaction to that is always, "why not
use one common copy of the code then?"
You could call it something like of_flat_dt_match_list() if that makes
more sense to you. Or just copy the for loop around, it's not much code.
- R.
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Benjamin Herrenschmidt @ 2008-08-20 21:37 UTC (permalink / raw)
To: Eran Liberty
Cc: Mathieu Desnoyers, linux-kernel, Steven Rostedt, linuxppc-dev,
Steven Rostedt, Alan Modra, Scott Wood, Paul E. McKenney
In-Reply-To: <48AC23F4.80900@extricom.com>
> Hmm... so whats now?
>
> Is there a way to prove this scenario is indeed the one that caused the
> opps?
I've verified in sim that the crash in do_lookup() I was seeing (similar
backtrace) was indeed caused by an interrupt coming between those two
instructions and clobbering the saved GPRs.
So I think it's very likely our problem.
Ben.
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-20 21:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Eran Liberty, Mathieu Desnoyers, linux-kernel, linuxppc-dev,
Steven Rostedt, Alan Modra, Scott Wood, Paul E. McKenney
In-Reply-To: <1219268189.21386.65.camel@pasglop>
On Thu, 21 Aug 2008, Benjamin Herrenschmidt wrote:
>
> > > As you can see, it restores r1 -before- it pops r24..r31 off
> > > the stack ! I let you imagine what happens if an interrupt happens
> > > just in between those two instructions (mr and lmw). We don't do
> > > redzones on our ABI, so basically, the registers end up corrupted
> > > by the interrupt.
> >
> > Ouch! You've disassembled this without -pg too, and it does not have this
> > bug? What version of gcc do you have?
>
> Oops, should have mentioned it ;-)
>
> 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
I'm running a 4.3.1 (Debian 4.3.1-2) on my powerbook. Perhaps the issue is
already taken care of.
-- Steve
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Benjamin Herrenschmidt @ 2008-08-20 21:36 UTC (permalink / raw)
To: Steven Rostedt
Cc: Eran Liberty, Mathieu Desnoyers, linux-kernel, linuxppc-dev,
Steven Rostedt, Alan Modra, Scott Wood, Paul E. McKenney
In-Reply-To: <alpine.DEB.1.10.0808200913070.13132@gandalf.stny.rr.com>
> > As you can see, it restores r1 -before- it pops r24..r31 off
> > the stack ! I let you imagine what happens if an interrupt happens
> > just in between those two instructions (mr and lmw). We don't do
> > redzones on our ABI, so basically, the registers end up corrupted
> > by the interrupt.
>
> Ouch! You've disassembled this without -pg too, and it does not have this
> bug? What version of gcc do you have?
Oops, should have mentioned it ;-)
4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Ben.
^ permalink raw reply
* Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
From: Arnd Bergmann @ 2008-08-20 22:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-mtd, Sebastian Siewior, tglx, Sean MacLennan
In-Reply-To: <20080820205958.GA13371@www.tglx.de>
On Wednesday 20 August 2008, Sebastian Siewior wrote:
> I didn't convert the NDFC driver to support OF because there are
> non-OF-aware platforms with the ndfc chip.
> All settings are mandatory except the oob layout.
Are you aware of Sean's patch from
http://patchwork.ozlabs.org/linuxppc/patch?id=20183 ?
What are the other platforms using it?
Arnd <><
^ permalink raw reply
* porting linux 2.6.27 to embedded powerpc board
From: Laxmikant Rashinkar @ 2008-08-20 23:24 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
Hi,
I have an embedded PowerPC (MPC8347) board that works fine with uboot and Linux 2.6.15.
I am trying to upgrade the kernel so that it runs on the latest release - Linux 2.6.27.
So far, I have gotten the kernel to compile on my platform, but of course it does not boot.
Things have changed drastically since 2.6.15 and the porting methodology used back then is obsolete now. Progress is a good thing :-) I have googled for info on how to accomplish this port but have found nothing so far. In particular, the fact that I am using uboot instead of open firmware makes the task a bit more daunting.
The file Documentation/powerpc/booting-without-of.txt gives some info on the flattened device tree and and at the end of the "board support" section it states "I will describe later the boot process and various callbacks that your platform should implement." but that description is not part of the document.
I am wondering where I can find more info that will help me accomplish this port.
thanks a lot for your help.
L.K
[-- Attachment #2: Type: text/html, Size: 1293 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